





a 


iano 


COOPERATION 


F Za A —— 
E 


FRAMEWORK & 
Ma 
BOTTLENECKS SS 












Activity 2 - deliverable 
June 2018 


Contact Person 

Dr. Irina Koller-Matschke 
Activity 2 leader 
irina.koller-matschke@bmw.de 


Copyright 

© 2018 by SOCRATES?” 

All rights reserved. No part of this publication may be reproduced, distributed, or 
transmitted in any form or by any means, without the prior permission of the publisher. 
In the case of noncommercial use, (parts of) this publication may only be used with 
acknowledgment of the source. 





COOPERATION 
FRAMEWORK | EA 





BOTTLENECKS 





SOCRATES?20 


SOCRATES?" is co-funded by 
SAFE GREEN E the European Commission 


TABLE OF CONTENTS 


Introduction. O aaa 5 
Definition and SCOPE... essessesesssecesceseecsecesscsessessecseseeeesesesseseacsesseenessesseeaseessseseseeseassaseasenens 6 
Key problem / cChallenge.......ceccscscsssecessssssesecsesseeseesesseeseeeseseaeeesesseseeseessesaeeeesaesseeeseaeeasees 9 
Approach Activity 2 ss. coi sev ici cadehcancteesceanteseeteatdsnavacs ddvaevacs a a a i 10 
Structure OF this repornirea na E T ENDRO T 13 
Management O 13 
DeVelOPMeMts.........cccecccscsssescecesseecceecsesecceesseseceeecsessesenceessesseseessesseeeesaeeseeaeeessaeeeseesersaaeensets 17 
Developments in AUTOMOTIVE industry .......cceeeceesessescesscteeseeeecsecseeseeeeeseeseeeeseceseeesrsaeceesats 18 
Developments in traffic management & information ....occnicncnnccoconononnnnonnnanonncnnnnnonnonannos 20 
Other relevant developments 00... ccesesceceecstcecceessessceeecesseeeecsesseeeeeeesseeeceeseeceeceeseesaeceeees 22 
Stakeholder needs and interests ..........ceccsscsessessceceeecsecseceecsesseeeecsessecaeeeecaeeaeeeseseaeerees 25 
IntrodUEtON intra ai atari 26 
ROad USERS oa 26 
Public road authorities......eseesessessessessnssessennennnnnnnnnnnnnensnnnnnnensennnnnensensensensonsensnnsonsennnessonann 27 
Public traffic management centres.....usessesessessenneneessennnnensensnnnensnnsennensensensnnsnnsensnnnsonan 27 
Data Provid Ors iii a aceite 28 
Service PFOVICELS.......cssescsessetesssessscseccesseccessescsecessesssacessesssssaceesssesasensesssaseaseessaseasensnsseasenses 28 
Automotive NUS iia A as 28 
CONC Mii 29 
Shared Visionado 31 
A Al OS Rem EEE EEE casien EEE LEERE ERS EEE CENT REENAUNEREN TEN FERIEN EETENE TEN EELER EEE 32 
The four elements of SOCRATES? ...ueeeseeseenennssnennennenensnennennnsnnsnnnnnnennensnnsnssensensnssensessnsenan 34 
Conelüsion. ans tenis Grade aan Aisin tn Te 39 
WSO CASES: nase lesen Aaa aa kn 41 
INTO UC Ni e iii 42 
A hen cevacdentevsciaheetaaeaviesalicvezacteaeeticeadeveniislactiveeesns its 43 
Actual speed and lane advices .......eeecessessssesececeeeseeseceesseescececsesseeeeeeseseeeeeesseseeeeesersaesensets 44 
Local information and hazardous warnings .........ccesceesceseeeesseeseeeeeteeeeeceesseeeeeeseesseeeesers 46 
Strategy 8: Coordination 00... cceeseeseeceeeesseeceescsecsceecsecseesecsecseeaeeeeeseeseeesseceaeeessesaeeaeens 47 
A easvvedesoisovesstaassvenseacavbeserscavasseeacaviaviovadessstssaens titesls 48 
DENT AA AAA 50 
Cooperation models viii a a 52 
CONCUSSION enrenar E E ie arrwtivien meeting 56 


7. Intermediary and Data FUSION... ecessececsescseeseceecseeseeeecsesseeeceeeeaeeaseesseseaeeeseessesensats 57 


Lia pe AAA een 58 
7.2. Different levels Of COMPLEXITY... ceeecscesceeeeeeeeeceecseceeceecsecsececsecseeeeeseeseeeeeessaeeeeeessesaeeeres 58 
LB ZFUNEIONS. a A A AA een A 59 
FA. Inter medi OPIO Sii A A ei 60 
8 Bore iria 65 
8.1... Data botten kS nn u ee vsdenladndutuanh asosi Ee 67 
8:2: "Technical DORE ii re ken 70 
8.3. Organisational bottlenecks .....cesesssesssesneseenennnennnnennennennennensennensensennnnnensenssnessensnssessensensnnsens 71 
8.4. Business-related bottlenecks...........ueesssessesnssenennnennennnnonnnnnennnnnnonnonnnonnnnononnennnonnnennnonn 71 
8.5, Legal bottlenecks: nia in ie ahnen O E i 72 
8.6... “Conceptual’bottlenecksi.n.. nn inini e eneninda redea iiaeie 73 
91. CONCUSSION AN 75 
A E A RO 79 
Appendix: Use Cases iaa dit 80 
Smart rOUtINE essen caschcavandaviedaveesdacaede cata seggezadatancagda i aaea eE ea aano dicate 80 
Use case functional description - Optimising network traffic flow... 81 
Use case functional description - Individual routing towards public event locations............ 85 
Actual speed and lane advice uo... sessecessecesecseeeeeesseaseceseeesceaesseaesseassaeseeesseeeseeacseeassaeaeees 88 
Use case functional description - Maximum allowed Speed ............ceeessesnesnnennesnennenennennnnn 88 
Use case functional description - Speed advice “Congestion ahead”... 91 
Use case functional description - Speed advice “Head of congestion”............nseeeene 93 
Use case functional description - Speed advice at traffic lights 0... eee eeneeteeeeseeeeeeteeneees 95 
Use case functional description - Speed advice at ShOCkwaV8S ...ooociccccconaconanonnnonnnnnacnnnannccnnnos 98 
Use case functional description - Lane information ...oooccicinnnonicocconnnconnnnnnnnnnnnanonononannnna rn conan 102 
Use case functional description - Lane advice at short on- and off-ramps „seses 104 
Use case functional description - Lane advice at traffic lights..................eeeeenennn 106 
Local information and hazardous WarNiNS............cccccscceeseescececseeseeceeeesseeseeesescesseesersaeceeeees 107 
Use case functional description - Road works warning.......nsenesessenssnsensenneneneennennnennnnennennnnen 108 
Use case functional description - Road condition warning..........uneeessesnesenneneesnennennennnnen 110 
Use case functional description - Emergency service protection ..ooccnonccnnnononnnncnnnnnnnranonnnnos 111 
Use case functional description - Environmental/Areal information and constraint.......... 112 


1. INTRODUCTION 





1.1. Definition and scope 


The SOCRATES”* project paves the way for the next generation of traffic management. 
Public and private parties cooperate to provide optimal routes and advice (faster, safer, 
cleaner) for the individual road users, also securing the collective interests via mobile/in-car 
and roadside services and (in the future) self-driving vehicles. 


Road networks, vehicles, road users, telecom networks, roadside systems, mobile and 
in-car systems, traffic centres and back offices together shape the traffic ecosystem. 
Improvements are possible both on the short term and the long term, with increasing 
numbers of connected and automated ITS systems enabling road users and self- 
driving vehicles to drive as efficiently and safely as possible, with as little damage to the 
environment as possible. 


1.1.1. Traffic Management 2.0 





SOCRATES”? is based on the strategy as developed by the TM2.0 initiative’. This platform 
originated in 2011 and has currently nearly 40 members from all ITS sectors (government, 
industry, research) focusing on new solutions for advanced active traffic management. It 
aims to agree on a set of common interfaces, principles and business models to facilitate 
the exchange of data between vehicles and Traffic Management Centres (TMC). This is 
crucial for improving the entire value chain for consistent Traffic Management and Mobility 
services. 


Traffic Management 2.0 is a new stage in the development of traffic management. In the 
past traffic management (TM) was mostly directed one way. A road authority informs road 
users on its traffic management measures or plans (TMP's) via Variable Message Sign (VMS) 
or other dynamic signalling. A road authority can also activate TMP's and dose traffic in the 
network via several (local) traffic control measures. Another stakeholder group in TM is that 
of traffic information service providers. They inform road users via navigation (embedded 
in-car or mobile) about the quickest or shortest route to be followed. However, currently: 


e Traffic management plans (TMP) are not part of the dynamic traffic information that is 
delivered via in-car or mobile devices today; 

e Individual vehicle behaviour (as available from the route guidance system) is not made 
available to the traffic management system; 

e Today's traffic control strategies do not address individual road users; 

e Today's private parties play an important role in collecting and enriching the underlying 
data; 

e Access to in-car and hand-held services (e.g. communication with road users) is the 
domain of private parties. 





1 http://tm20.org/ 
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Figure 1: TM2.0 concept 


The TM2.0 concept aims to merge the previously divided worlds of centralised traffic 
management and in-vehicle road user information. For the TM2.0 concept to become 
operational, a framework of closer cooperation between public and private stakeholders 
with respect to each other's priorities needs to be defined. The TM2.0 concept is based on 
achieving a ‘win-win’ for all stakeholders involved, while implementing Interactive Traffic 
Management. 


The TM2.0 concept is based on the: 


e exchange of all available relevant data between stakeholders in the control loops; 

e provision of individual communication channels between TMC's and road users/service 
providers; 

e development of a new interface for data exchange between TMC's and service 
providers, necessary for individual and collective traffic information and signage; 

e development of a cooperation framework between public and private stakeholders ; 

e development of (new) business models with benefit to all stakeholders. 


There is an added value expected for the involved stakeholders: 


e Traffic managers can reduce congestion, reduce emissions, improve traffic management 
with additional data sources and possibility to reach road users directly, and possibly 
replace existing data collection and collective information (VMS) technologies; 

e Road users can avoid congestion, receive more relevant information, have better road 
safety and get the best route advice; 

e Service providers can provide the best route advice well in advance instead of 
congestion information, and regional information becomes part of an integrated 
service. 


Possible new constellations for such cooperation also raise some items for discussion, for 
instance: what justification does a road authority have to override an individual's freedom 
of choice and to regulate service provision in an open market? And why should road 
authorities make investments which improve the quality of services provided by service 
providers and therefore increase the latter's revenue? How can service providers provide 
added value in cooperative ecosystems, while still enabling competing business models? 
SOCRATES?" aims to deploy the generic TM2.0 concept by developing a cooperation 
framework and test the feasibility and advantages of interactive traffic management 
services in four regions in Europe. SOCRATES?” and the TM2.0 platform will set up a close 
collaboration through continuous exchange of findings and results via membership of the 
TM2.0 Steering Group. 


1.1.2. SOCRATES?” general structure 





SOCRATES?” will build on the strategy of TM2.0, elaborate an approach and test actual 
services in four regions in Europe. The pilots are located in the regions of Amsterdam, 
Antwerp, Copenhagen and Munich and include motorways, regional roads, urban- 
interurban interfaces and urban roads. It is expected to lead to more business 
opportunities for the private partners, a more cost-effective traffic management for the 
public authorities and better service for the road users. 


The elaborated concept of Interactive Traffic Management needs to be tested in reality 
before it can be widely deployed. Open questions on such deployment, for instance 
regarding optimal way of cooperation, business models, legal framework and scalability of 
the concept, will be explored during the various phases of SOCRATES”. 

The SOCRATES?” project consists of 9 activities. As shown in the diagram in figure 2, the 
project follows a V-model approach. In brief: a common framework is defined (Activity 2) 
and then specified for the four pilots (Activity 3). This is validated in the pilots (Activity 4-7), 
evaluated (Activity 8) and the results used to update the framework (Activity 9). 


CEF call on ITS Public policies and business strategies 


Activity 1: Project management 


Activity 2: Integrated traffic Activity 9: 
management framework Consolidation 


Activity 3: Common designs Activity 8: 
and specifications Evaluation 


Activity 4, 5, 6 and 7 Pilots in the regions of: 
Amsterdam - Antwerp - Copenhagen - Munich 





Figure 2: V-model approach 


This report describes the results of Activity 2. The goal of Activity 2 is to develop an optimal 
framework for cooperation between the public and private partners, as a basis for a 
European deployment of Interactive Traffic Management. Activity 2 scopes the strategic 
level of such cooperation, while the subsequent activities also cover the tactical and 
operational levels. 


Activity 2 objectives: 


e to achieve a shared vision between the partners about Interactive Traffic Management; 
e to commonly define a framework for Interactive Traffic Management and to identify and 
analyse potential bottlenecks. 


1.2. Key problem / challenge 


The transport of people and goods via the road is by far the largest part of the mobility 
system in Europe. Road traffic enables human and goods transport; for instance 
commuting between home and work, travel for leisure, distributing materials and products 
between factories and retailers. 

Many jobs are directly involved in developing, building, operating and maintaining the road 
transport system. But many more jobs depend on a good accessibility by road to these 
destinations and thus depend on efficient and safe road traffic. 


The European road transport system and road traffic contribute significantly to the quality 
of life of the European citizens and to the European economy and jobs. But this comes with 
a huge cost in Europe each year: In 2015, more than 26,000 people died and more than 
1,000,000 people were injured on the roads of the European Union’; direct costs due to 
delays amount to more than 20 billion euro's; cities fully blocked; reduced accessibility to 
industrial areas etcetera. Forecasts show a significant further increase of these problems in 
the years to come. 


So the challenge for SOCRATES?” is to work on traffic management that improves traffic 
flow and reduces traffic problems with: 


e asafer, cleaner and more efficient traffic flow and optimum use of the road capacity; 

e better services to the road users and better quality of life for citizens; 

e amore cost-effective traffic management by optimising the use of existing road 
capacity; 

e economic growth and more jobs by reducing traffic problems and by creating new 
business opportunities. 





2 https://ec.europa.eu/transport/road_safety/specialist/statistics_en 


The needs and interests of stakeholders are different and it may be a challenge to find 

a model that is attractive for all. The SOCRATES2° partners want to establish something 
new and not just improving an existing concept. To do so, they recognised that the idea of 
influencing traffic has to be transformed into supporting people travelling from A to B. As 
a result, SOCRATES?° focuses not just on technology or the traffic management process 
but also on the customer itself as a stakeholder in the loop. People are connected with 
others continuously, have huge amounts of data available to make any decision at any time 
they want, share their experiences with others (via social media platforms) and thus are 
expecting high degrees of freedom in decision making, including those related to travelling 
from A to B. SOCRATES?* wants to utilise these opportunities to face the challenges 
identified. 

Interactive Traffic Management, based on the TM2.0 vision, has the potential to solve 

the problems by improved cooperation, making full use of each other's data sources and 
technology with valid business models. 


1.3. Approach Activity 2 


The SOCRATES?” project consists of 9 activities. A common framework is defined in Activity 
2 and then specified for the four pilots in Activity 3. This is validated in the pilots itself 
(Activity 4-7). 


The work in Activity 2 is based on the knowledge and experiences of the SOCRATES?0 
partners. All SOCRATES?* partners provided their input to all tasks in this Activity. Since 
many partners with different backgrounds and also different liaisons with other projects, 
such as TM2.0 and C-Roads, have been involved, a wide spread of views and opinions is 
covered. 


To find a consensus between the SOCRATES?? partners several participation formats were 
used: 


Detailed work within 4 Focus Groups, meetings every 2-3 weeks 

e A Focus Group was a temporary ‘pressure cooker’ workgroup consisting of partner 
representatives with particular interest or expertise. A specific topic was discussed and 
elaborated in detail; 

e The links to the tactical and operational levels, addressed in the following activities were 
specified in the Focus Groups; 

e The following Focus Groups (FG) were established: 
= FG1 - Vision 
= FG2- Intermediary and Data fusion 
a FG3- Strategy and Coordination 
m FG4- Use cases and Data exchange 
These groups worked mostly in parallel, but the logical order is shown in figure 3. 


Focus Group 1 
Shared vision 


Focus Group 4 
Use cases & Data exchange 


Focus Group 3 
Strategy & Coordination 


Focus Group 2 
Intermediary & Data fusion 





Figure 3: Focus groups 


This is also the order in which the results are presented in this report. It starts with an 
elaboration of the vision which is the basis for further work. Since the road user is a central 
element in the vision, specifying use cases is next. These include a list of steps defining 

the interactions between actors and systems to achieve the goals. Then, it is important to 
assess how the stakeholders can cooperate to be able to take these steps. And finally, the 
concept of the intermediary is explored, based on the use cases and cooperation models. 
An intermediary could have a role in data exchange coordination, aggregation, fusion, 
quality control and common picture creation. 


2-day workshops every 2 months with participation of all partners 

e Each partner provided its understanding on expectation and vision on Interactive Traffic 
Management (urban and national road authorities, intermediaries, service providers 
and the car industry); 

e On top of that, the project used a design thinking approach, to come up with joint ideas 
of solutions to development and test within the project; 

e Agreements on clustering the topics, general architecture and relations to the other 
activities were defined; 

e The details elaborated in 4 Focus Groups were presented and discussed with all 
partners to ensure common understanding and level of knowledge. 


Desk research to include as much relevant aspects as possible 
e Input through liaisons with projects and initiatives like EU-EIP, DATEX II, CEDR; ERTICO; 
TEAM, Lena4 ITS etcetera. Specifically, the SOCRATES?” project is building on the 
foundations that are established by the C-ITS deployment platform?, the C-Roads 
platform’ and the TM2.0 platform. 
= The C-ITS platform delivered their phase 2 final report in September 2017. One of 
the annexes to this report is the final report of the working group on Enhanced 





3 https://ec.europa.eu/transport/themes/its/c-its_en 
4 https://www.c-roads.eu/platform.html 


Traffic Management. Both documents are very relevant to the work of SOCRATES?° 
and information is included in this deliverable. SOCRATES? is very much in line with 
long term vision of the platform: ‘A Connected traffic system in which all elements 
act collaboratively, providing the best achievable balance between the individual's 
needs and the collective's best interest, as for safety, flow efficiency and emission 
reduction.’ 
Specifically, the project takes into account the following requirements mentioned by 
the platform: 
> ‘to ensure continuity and interoperability, the Cooperative Traffic Management 
Services will not be limited to any borders.’ 
> ‘to ensure flexibility, the tools to develop the Cooperative Traffic Management 
Services shall be modular, scalable, replicable and compliant with standards.’ 
> ‘the tools to develop the Cooperative Traffic Management Services shall promote 
joint cooperation.’ 
= A further platform requirement is: ‘the tools to develop the Cooperative Traffic 
Management Services will take stock of [...] the deployment of the C-ITS Pilots of 
C-Roads.’ The C-Roads platform published a template for use case descriptions. This 
template is used for the SOCRATES?” work. Furthermore, the contents of the C-Roads 
use case specifications was used as input for the project, as were contents from the 
projects “C-the Difference”, “C-ITS Corridor”, “InterCor” and “Shockwave traffic jams 
A58". 
= The TM2.0 platform delivered reports on various topics. The most important one for 
developing the SOCRATES?" vision is the report on ‘Traffic Management 2.0, the Win 
- Win”. The paper discusses the value proposition of TM2.0 and relevant information 
was used for the collaboration models. Next the report on 'Contractual agreements 
and schemes” was used for elaborating ideas on business models (rewarding and 
incentives). Finally the report on ‘Barriers and Enablers” was the basis for Chapter 6 
of this report. 
= The project set up a stakeholder analysis with relevant organisations, initiatives and 
projects. This list is used for gathering further content for the work of the project. 


The SOCRATES?* Cooperation Framework consists of a set of options for cooperation and 
implementation of services. At this stage no definite choices are made for deployment in 
de pilots. Choices between these options are made in Activity 3 and will be described in the 
relevant deliverables. 





5 Rehrl, K., Salanova, J., Laborda, J., Tzanidaki, J., van Waes, F., 2016. Traffic Management 2.0 - The Win-Win. 11th ITS European 
Congress, June 2016, Paper no. EU-SP0162. 

6 Vlemmings, T., Vroom. O., Tzanidaki, J., Vreeswijk, J., Hofman, P., Spoelstra, J., Rodrigues, N., 2017. Contractual Agreements in 
Interactive 7 Traffic Management - looking for the optimal cooperation of stakeholders within the TM 2.0 concept. 12th ITS 
European Congress, June 2017, Paper no. ITS-TP0785. 

7 Traffic Management 2.0 (TM2.0), 2014. Report of the Task Force 2 on Enablers and barriers, January 2015. 
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1.4. Structure of this report 


This Chapter 1 introduces the project, the concepts behind it and explains the process. 
Chapter 2 describes relevant developments for the projects in the field of mobility and 
society as a whole. Chapter 3 is about stakeholder needs; what is driving the organisations 
to be part of this strategic alliance between private and public organisations? 

Chapter 4 presents the results of Focus Group 1: Vision. What is the overarching philosophy 
of SOCRATES??? It gives guidance to the themes elaborated by the other Focus Groups and 
provides the overall learning objectives for the project. 

The vision is translated into use cases in Chapter 5 (work of Focus Group 4). 

Chapter 6 & 7 contains the work of Focus Groups 3 and 2 respectively. What are the 
strategy & coordination options for the cooperation between stakeholders, and what are 
the options for intermediary & data fusion? 

Chapter 8 is about bottlenecks for Interactive Traffic Management. The report concludes 
with Chapter 9 - conclusion and an appendix with the detailed use case descriptions. 


1.5. Management summary 


The SOCRATES?” project paves the way for the next generation of traffic management. 
Public and private parties cooperate to provide optimal routes (faster, safer, cleaner) for 
the individual road users, also securing the collective interests via mobile/in-car and road- 
side services and (in the future) self-driving vehicles. 


SOCRATES?” partners believe that deployment of the SOCRATES?" vision will lead to a WIN- 
WIN-WIN situation for all actors in the Traffic Management eco-system: 


e WIN for the road user: 
= they receive the best route options based on interactive traffic management 
principles 
a they receive aligned traffic information provided on-trip to road users, eliminating 
confusion on todays conflicting road-side and in-car information 
= they will be able to provide feedback on current traffic situation to the Traffic 
Management operators 
= will feel as real customers of traffic infrastructure providers 
e WIN for public Traffic Management Centres: 
a will be able to substantially optimise Traffic Management operations 
a will become part of a holistic Traffic Management ecosystem, considering the 
expertise and assets of different parties and market players 
e WIN for private Service Providers: 
= will expand their services to seamless door-to-door traveller assistance 
m will serve innovative use cases 
= will take on active responsibility to improve traffic efficiency and safety 
m will keep the competitive freedom how to set-up services towards the travellers 


To reach the mentioned WIN-WIN-WIN situation, SOCRATES?* aims to agree on a set of 
common interfaces, principles and business models to facilitate the exchange of data 
between vehicles and TMC's. This is crucial for improving the entire value chain for 
consistent Traffic Management and Mobility services. 


SOCRATES?” will test actual services in four regions in Europe. The elaborated concept 
of Interactive Traffic Management needs to be tested in reality before it can be widely 
deployed. Open questions will be discussed, for instance regarding optimal ways of 
cooperation, business models and legal framework. 


This report describes the results of SOCRATES?® Activity 2. The goal of Activity 2 is to 
develop an optimal framework for cooperation between the public and private partners, as 
a basis for a European deployment of Interactive Traffic Management. Activity 2 scopes the 
strategic level of such cooperation, while the subsequent activities also cover the tactical 
and operational levels. 


The partners wanted to establish something new and not just improve an existing concept 
of cooperation. To do so, they recognised that a paradigm shift should be made from 
‘managing and influencing traffic’ to ‘supporting people on their travel from A to B’. Goal 

is to create synergies between actions of the individual road users with the collective 
mobility objectives, to bridge the innovative developments in the vehicle and in the traffic 
management, while giving value to the legacy and creating new business opportunities. 
This goal is summarized in the following statements: 


Customer: “CEO of my own journey!” 

Community: “Choosing our Mobility habits” 
Cooperation: “Joint effort, shared benefit” 
Technology: “Facilitating the journey, unperceived” 


Specifying use cases is the next step and this was done around three themes: 


1. Smart routing 

2. Actual speed and lane advices 

3. Local information and hazardous warnings 

These include a list of steps defining the interactions between actors and systems to 
achieve the goals. 


Then, it is important to assess how the stakeholders can cooperate to be able to take these 
steps. For that a theoretical framework describing options for cooperation was created, 
and a first inventory of preferred options was made. 


Finally, the concept of the intermediary was explored, based on the use cases and 
cooperation models. An intermediary could have a role in data exchange coordination, 
aggregation, fusion, quality control and common picture. The group came up with a 
number of typical options for the intermediary role, to be selected and elaborated in the 
next activities of the project. 


This Activity 2 report presents a list of options for cooperation and implementation of 
services, no definite choices are made. However, a first selection of options to consider in 
the follow up of the project is done. Variations to these options are possible. Some options 
are not included in this report because they are not in line with the projects goals, not 
innovative or not realistic. Choices between these options will need to be made in the next 
phases of the project. Different options may be tested in the respective pilots areas, or they 
could be tested in parallel within a test site. 


Now the common framework is defined in Activity 2, the approach will subsequently be 
specified for the four pilots in Activity 3. The plans are then validated in the actual pilots 
(Activity 4-7), and evaluated in Activity 8. The results will be used to update the framework 
(Activity 9). Information on the results of these activities will be published in future 
deliverables. 
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Many developments in mobility have an impact on the work of SOCRATES2°. This 
chapter describes the developments in automotive industry, traffic management & 
information, and other areas that are considered to be relevant for SOCRATES?°. The 
project partners are able, to some extent, to influence and steer developments, while 
other trends, though relevant, are outside the scope of influence. However, the reason 
why people travel and the role of city planning in this is outside the SOCRATES?” scope. 
This overview can be seen as the context for the SOCRATES?” vision developed in 
Activity 2 and that is described in Chapter 4. 





2.1. Developments in automotive industry 


2.1.1. Connected and automated cars 





A major development is that cars are becoming increasingly automated. One could say that 
this already started with the introduction of the cruise control service, and gradually many 
more services are being deployed on the way to (possibly) full automation. There are many 
new entrants to this market (non-traditional car manufacturers). 

In this field, six levels of automation are distinguished, with level O being ‘no automation’ 
and level 5 being ‘full automation’. Some companies already offer level 2 automation. An 
opinion often heard is that automation on highways is less complicated while city centres 
with many pedestrians and cyclists are very complicated areas for (fully) automated cars. 


Transition of responsibility —————————>> Machine 


TODAY 


Awareness for General awareness 


Early Traffic control take over 
warning systems (e.g. congestion 
such as assistent) 
cruise control / s 
speed assistant No take over No driver 
Take over request 


No active 
assistance system 


request (“Mind-off") 
(“Eyes-off") 


(“Hands-off”) 
("Feet-off”) 





Figure 4: Automation levels 


Another distinction is ‘connected automation’ versus ‘standalone automation’. Some 
manufacturers are developing an autonomous car that drives based on sensors that just 
look to the outside world, while others are aiming to be connected to the outside world 
(other vehicles and roadside equipment) and use the information received as additional 
source. 

Being connected is often described as V2V (Vehicle to Vehicle communication) and V2I 
(Vehicle to Infrastructure or roadside communication). Communication technologies 

like ‘ITS G5’ (also called wifi-p) and cellular (mobile phone network) enable cooperative/ 
connected cars. Cellular communication is currently developing towards the fifth 
generation (5G) promising better performance (e.g. on latency). 
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Connected cars have the benefit that they can act as sensor: various types of data could be 
made available for traffic management purposes - not just vehicle positions but also data 
like slippery road and pot hole detection. 

Furthermore, it is a question how private ownership of cars will develop. If most or all cars 
can be used by everyone, for individual or shared rides, the amount of cars and travel 
demand could decrease. And this would create a different kind of market situation for 
traffic management/information service providers. 

Apart from private vehicles, automation is also being developed for buses and trucks 
(especially platooning). 

There are many contradicting opinions regarding the speed of developments, ranging 
from 2025 to 2070 for full automation, while others think it will never become a reality in 
city centres. A variety of open issues exist, including liability, legislation, privacy, security, 
standardisation etc. 

An important question is what impact automation will have on infrastructure and traffic 
management. Authorities have relatively long planning cycles, and they would like to 

know how the roads and roadside systems should be adapted and what opportunities it 
brings. For what kind of vehicles should traffic management be prepared? With upcoming 
automation of vehicles, traffic management should not just focus on the driver as end user 
but also the vehicle algorithms, which is another kind of challenge. How the deal with a mix 
of human and automated decision making? 


2.1.2. Electrification of vehicles 





Another major development in the automotive industry is electrification of vehicles. In the 
discussions around climate change, many are calling to decrease the use of fossil fuels. Air 
pollution is a problem, mostly in cities, and electric vehicles are far less polluting. 

The growing number of charging points as well as improvements in batteries to enlarge the 
trip range make electric vehicles more and more attractive. The average trip range of most 
car drivers within one day is around 40 km, meaning that the actual cars on the market are 
sufficient for the biggest part of mobility habits so far. The main challenge is to take note 

of doubts from the users, and make them familiar and feeling comfortable with electric 
cars. This is a common task for politics, society and industry. Some governments have been 
backing the developments e.g. by tax incentives, open question is how this will work on 

the long term. Ongoing electrification of the vehicle fleet is often assumed, and that would 
have an impact on pollution strategies - also in traffic management. 

So far, electric cars are mostly private vehicles although there are many initiatives around 
trucks as well, and electric buses are quite common already. A market share for new 
electrically chargeable vehicles is to be assumed in the range of 2 to 8% by 2020 to 2025, 
based on today's market‘. 





¿Website European Automobile Manufacturers Association http://www.acea.be/industry-topics/tag/category/electric-vehicles 
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2.1.3. New business models 





Automation will bring many opportunities for car sharing, private ownership of cars may 
not be necessary anymore. The development of ‘Mobility as a Service’ has a link with this; 
consumers can use the mode of transport they like with one subscription. For each trip 
they can choose an (automated) car, bike or public transport e.g. depending on cost, time 
of day and personal preferences. Existing and new mobility stakeholders are starting to 
offer the MaaS concept. These organisations, some of which also own a fleet of vehicles, 
can have a large influence on management of the transport system. 


The goal is to raise quality of life as well as quality of mobility at the same time, especially in 
the cities. There are two key action points: more customer focus and utilisation of efficiency 
potentials. There are already existing evolutions that are the base for the paradigm change: 
changing mobility preferences and new technical possibilities due to emission free power 
units, digitalisation and autonomous driving. 





2.2. Developments in traffic management & information 


2.2.1. Data (detection, fusion and completion) 





Traditionally, only road authorities and operators gathered data. Over the last 20 years, 
more and more data sources have emerged, from the likes of car manufacturers, 
navigation system suppliers, telecom operators and specialised service providers. It is 
expected that the amount of data will increase massively with connected and automated 
vehicles. 

To have the full benefits of these data sources, data would need to be combined. So 
exchange of data between organisations (both public and private) has started and is 
growing fast. This means that there is an increasing need for data management, quality 
checks, aggregation, big data analytics, and fuzzy logic. Some of these tasks can be done 
by the organisations themselves, while for others specialised organisations are better 
equipped to fulfil the tasks (intermediary organisations). 


Ongoing debates are: 


e The openness of data (what data is accessible to whom and under what conditions - 
financial, privacy etcetera) 

e Can existing (more expensive) data collection techniques disappear and be replaced by 
new technologies? 


One of the main forums for this discussion is the ‘Data Task Force’. The Declaration of 
Amsterdam on "Cooperation in the field of connected and automated driving" was signed 
in April 2016 by the EU transport ministers, European Commission and ACEA (European 
Automobile Manufacturers Association). As a follow up, high level meetings are held and 

a few member states have started to work on data sharing with OEMs. ACEA stated? that 
they want to find a solution for secure and safe access to vehicle data to interested market 
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participants. The idea is that this statement is a good start for improving road safety 
through data sharing by OEMs. The task force should focus on creating the necessary high- 
level agreements for doing this. 


2.2.2. Control (decision support, evaluation, presentation & control) 





Traditionally, only road authorities and operators sent messages to road users, based 

on legislation (traffic regulations, e.g. closed lanes, traffic signals) and calculation of 
collective optimum (traffic management, routes advice on variable message signs). 

More and more, service providers are now advising users, with a focus on an individual 
optimum. New technologies like smart phones bring new opportunities to influence 

travel behaviour. Stakeholders should cooperate to have the best outcome for all. For a 
service like smart routing, the goal would be to reach a balance between an individual and 
collective optimum. For other services like ‘slippery road warning’ there is a shared interest 
anyway. Data is often available in real-time which enables better traffic management. And 
algorithms are becoming available that predict the traffic situation enabling proactive 
traffic management (e.g. preventing congestion). 


2.2.3. Services to consumer 





Innovative services to consumers are emerging, making full use of new technologies. 

Many stakeholders and projects are working on these services. These are often referred 

to as ‘Day 1’, ‘Day 1.5’, ‘Day 2’ use cases to indicate envisaged chronological order of 
implementation. 

The C-Roads Platform’? is a joint initiative of European member states and road authorities 
for testing and implementing C-ITS services in light of cross-border harmonisation and 
interoperability. Many countries and projects are active within this platform. InterCor is one 
of these projects. The platform is co-financed by the European Commission. 

At an earlier stage, the ‘Amsterdam Group?” and ‘C-ITS deployment platform”? (specifically 
the Enhanced traffic management working group) discussed lists of services. Another 
example of an ongoing project is ‘Concorda’ (Connected Corridor for Driving Automation). 
These initiatives and projects are working in cooperation to ensure harmonised 
implementation and to test C-ITS implementations all over Europe. Questions for all of 
these projects are: what are user needs and how can we ensure sufficient compliance 

by the road users? Information services to users have varying requirements in terms of 
latency of information. For safety functions, near real time information may be required 
while routing advice is mostly less time critical. This means something for the requirements 
on the communication technology. 

In SOCRATES”? Activity 2, three types of use cases are developed, each with a set of sub-use 
cases. These are described in Chapter 5. 





2 http://www.acea.be/press-releases/article/automotive-industry-joins-forces-on-access-to-vehicle-data 
https://www.c-roads.eu/platform.html 

1 http://www.amsterdamgroup.eu/ 

"2 https://ec.europa.eu/transport/themes/its/c-its_en 

1 https://connectedautomateddriving.eu/project/concorda/ 
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2.2.4. New frameworks (new actors, changing roles, new business models, public- 
private TM, ...) 





There is an obvious need in the traffic management world to collaborate to take services 
for road users to the next level. The end of business models is in sight due to wide 
availability of (free) traffic information services while new (in) car technologies make 
innovative services possible. So traffic management will become more of a collaboration 
between public and private stakeholders: 


e What will this shift mean for public organisations? Will their only task be to set the 
framework conditions and make legislation? Or will they have a more active role? 

e What will this shift mean for private organisations? What will be the business model? Are 
there new entrants? Will it be global players or regionally/locally organised businesses? 


The SOCRATES?” project will explore various options for new forms of collaboration. 


In general, developments on traffic management and information are captured within the 
‘transitions’ of the Connecting Mobility initiative in the Netherlands. This long-term road 
map distinguishes six routes": 


A. from non-personalised services to personalised services 

B. from separate and partially competing to a collaborative mixture of collective individual 
services 

C. from communication via roadside equipment to interaction between roadside and 
vehicles 

D. from specific solutions to (nationally) agreed standards 

. from contractor to entrepreneur and public-private collaboration 

F. from closed to easily exchangeable data 


m 


2.3. Other relevant developments 


2.3.1. Organisational developments (public-private cooperation) 





Since the concept of 'government' exists, there is an ongoing debate on what tasks the 
government has, what tasks is does not, and what government responsibilities can be 
transferred to private organisations (and under what conditions). 

Important discussion items are accountability, efficiency, innovation, market failure, 
etcetera. Almost everyone agrees that governments should make legislation and that 
companies are better at some tasks than governments and the other way around. 
One could say that there is a constant shift of tasks between public and private 
organisations, for each policy area including transport and mobility. An example of 
this is the ‘Delft deal’ in the Netherlands, where public and private partners came to an 





"4 https://connectingmobility.nl/en+home/en+smart+mobility+overview/Transition+routes+and+transition+plateaus/default.aspx 
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agreement on collection and distribution of traffic information. For both sides there is a 
paradigm shift, towards the perspective of road users and consumers. 

Another current general trend is the fear that big global companies will dominate markets; 
local players do not have any opportunities and national governments find it hard to have 
an influence. 


2.3.2. Environmental developments (green, sustainability, ...) 





Climate change is one of the biggest topics in the world at the moment. Almost every 
country signed the ‘Paris Agreement’ setting the world on course to keep global surface 
temperatures from rising 1,5 degrees Celsius above where they were before the Industrial 
Revolution. 

Road transport is one of the major areas on which this has impact. Electrification, 
promoting clean transport modes and influencing demand are part of governments’ 
strategies. It is not just about less greenhouse gases, but also about pollution with negative 
health effects. 

In practice, governments are trying to balance between these goals and economic 
development goals. Ideally, these goals can be combined. 


2.3.3. Political developments 





Notable political developments are the increased attention for: 


e Safety and security: protection of society against terrorism; 

e Safeguarding privacy in the context of many new technologies; 

e The benefits of automation versus job losses/skills needed from workers, and the 
distribution of wealth. Who profits from new technologies? 

e Safeguarding national (economic) interests versus the benefits of international 
cooperation; 

e Open data policy. 


2.3.4. Legal developments (privacy and security) 





Specific current legal developments are: 


e Stricter privacy rules; from May 2018 the EC will enforce the General Data Protection 
Regulation (GDPR); 

e Recent open data legal framework; 

e Legislation on smart mobility; based on the C-ITS deployment platform documents, the 
EC is discussing the introduction of legislation (‘delegated act’) with stakeholders. This 
could have an impact on data provision by public and private organisations. 

The Declaration of Amsterdam and its Data Task Force are already working on this; 

e Further legislative discussions are ongoing (see political developments above). 
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3. STAKEHOLDER NEEDS 
AND INTERESTS 








3.1. Introduction 


Before determining a vision on Interactive Traffic Management, it is necessary to have a 
good overview of the needs of the involved stakeholders. In this chapter, the needs and 
interests are listed based on literature, reports from other projects and input from the 
consortium partners”*. This overview can be seen as the context for the SOCRATES?* vision 
developed in Activity 2 and that is described in Chapter 4. 


3.2. Road users 


In recent years several projects have been researching, testing and developing several 
day-one C-ITS services (C-ITS Corridor, C-Mobile, Compass4D, C-The difference, CODECS, 
InterCor, etcetera). Within each project several user orientated services have been 
developed. 

Desk research has been carried out within SOCRATES2° to determine what user needs have 
been resolved within the services of the mentioned projects. From the projects limited 
information is found about road user needs; for instance the Amsterdam Practical Trial 
showed that road users are interested in pre-trip information. Actually, SOCRATES?” still is 
one of the first projects of this kind where the user is explicitly in scope. 

A way to resolve this missing insight could be to interpret the available evaluation data. 
This will only give a selected view on the topic however, as the test user only gave feedback 
on the supplied solution and has not been asked, regardless of any solution or desired 
development, what he thinks is needed. 

The image below illustrates this issue". The image depicts in green the overlap between 
road user needs and technical feasibility. 

Within the SOCRATES? project it would therefore be advisable to try and create this much 
needed insight in user needs per service or use case. Knowing what the user wants and 
expects will help in developing a service from which all stakeholders (Service Provider, 
Road Authority and Road User) will benefit and will use for a longer period. 





Figure 5: User needs 





15 During the kick off meeting of the project, each stakeholder presented its needs and the summary is included here. 
16 Source: http://blog.strategyzer.com/posts/2018/2/27/do-you-understand-what-customers-want-and-can-you-build-it 
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3.3. Public Road Authorities 


The needs of road authorities can summarised as follows: 


Meeting policy objectives, such as: 

High availability of roads 

Optimising use of existing roads 

Safe roads 

Low environmental impact (noise and air pollution reduction) 

Fair access to road infra 

Thriving economy 

Reach organisational goals in an efficient way 

Insight on how to meet policy targets in this transition from ‘being the traffic manager’ 

to the “collaborative arena' 

e Competition among private stakeholders delivering services in traffic management 
chain 

e Viable business models for the private stakeholders 


Amongst other things this requires: 


e The right tools to meet the legal responsibilities of road authorities 
e Multimodal information 
e Reliable, high-quality data 


3.4. Public Traffic Management Centres 


The needs of Public Traffic Management Centres can be summarised as follows: 


e Meeting operational policy objectives and contribute to the policy objectives mentioned 
above (such as: road safety, noise and air pollution reduction, fair access to road infra, 
optimal use of road capacity, thriving economy) 

Being able to proactively manage traffic on its roads 

Being able to reactively manage traffic in case of congestion, events or accidents 
Having access to all existing channels to road users (roadside and in-car) 

Having access to sufficient data, actuators and/or other stakeholders' channels to 
manage traffic. Better insight on what is happening and will be happening on the roads 
e Provision of relevant, accurate, consistent information to road users, always 

e Reliable, high-quality data 

e High impact of advice to road users 
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3.5. Data Providers 


The needs of data providers can be summarised as follows: 


e Being able to run the business, building a business case. ‘Data receivers’ provide data, 
money or other assets in return 
e Consent from owners/producers of data to process and use data 


3.6. Service providers 


The needs of service providers can be summarised as follows (this includes private 
organisations providing of services to road users and intermediary services): 


e Being able to run the business, building a business case. Having enough customers 
(B2C, B2B or B2G) 

Permission to run a service (where applicable) 

Legislation enabling innovation 

Level playing field 

Sufficient data to roll out their service 

Sufficient intelligence to run a successful service 
Assessment of data quality (certification) 

Automation of data chain 

Standardisation of data exchange 

Shared services on data exchange 

Decision support systems 

Scalable solutions (can be used in other geographic areas) 
Focus on road user 

Continuous development/improvement, being future-proof 





3.7. Automotive Industry 


The needs of the automotive industry can be summarised as follows: 


e Being able to run the business, building a business case. Having enough customers 
(B2C, B2B or B2G) 

Permission to sell their product (certification) 

Legislation enabling innovation 

Level playing field 

Focus on road user 

Scalable solutions (can be used in other geographic areas) 

Being able to make products that optimise the added value automated and self-driving 
cars can bring to the road users and to society 

e Continuous development/improvement, being future-proof 
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3.8. Conclusion 


It is necessary to have a good overview of the needs of involved stakeholders, as context 
for developing a vision. This Chapter shows that the needs and interests of stakeholders 
are in some extent overlapping but are different on other aspects, and it may be a 
challenge to find a model that is attractive for all. Interactive Traffic Management as being 
developed in SOCRATES?° has the potential to solve the problems by improved cooperation 
making use of each other's data sources and technology with valid business models. 
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4.1. General 


The goal of SOCRATES?” is to develop and test an optimal framework of cooperation 
between the public and private partners, as a basis for European deployment of Interactive 
Traffic Management. The first period of the project scopes the strategic level of such a 
cooperation (Activity 2), while the subsequent activities of the project cover the tactical and 
operational levels (Activity 3-7). Activity 2 gives the guideline for the subsequent activities 
by describing the key questions that should be solved and to ensure that the different 
stakeholders and target groups are addressed in the inventions. 


In Activity 2, the partners of SOCRATES?” assembled a shared vision on Interactive Traffic 
Management. Elaborating on the principles of TM2.0, this shared vision identifies the 
individual and joint motivations, interests and expectations regarding: 


participating in SOCRATES2° 

the road users (the end users); 

developments in technology, in particular data, roadside systems and in-car services; 
the organisations involved (road authorities, intermediaries, service providers and car 
industries); 

e relationships between the organisations and conditions for optimal cooperation. 


The partners wanted to establish something new and not just improve an existing 
concept of cooperation. To do so, they recognised that a paradigm shift should be made 
from ‘managing and influencing traffic’ to ‘supporting people on their travel from 

A to B’. Goal is to create synergies between actions of the individual road users with the 
collective mobility objectives, to bridge the innovative developments in the vehicle and 
in the traffic management, while giving value to the legacy and creating new business 
opportunities. 


As main learning objectives the following aspects have been defined: 


e To explore what use cases of Interactive Traffic Management can be successful in a 
collaborative public-private context: 
a demonstrate the impact of private services on public objectives 
= how can public assets and operations add value to private services? 
e To explore what business models for Interactive Traffic Management are feasible in a 
collaborative public-private context: 
m how can the road users be served in the best way? 
= how can private organisations be rewarded for positive impact on collective goals? 
(impact = functionality x number of users) 
= search for ‘impact driven’ business model for private parties with in-car traffic 
management 
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e To explore how to organise the public-private collaboration: 
m making 1 + 1=3> road user win + public win + private win. How can the road users 
be served in the best way while also pursuing societal goals? 
= what are the key elements determining scalability and success of the use cases? 
scalability = technological, data quantity/quality, commercial including sustainable 
business models and organisational 
e To explore how roles and responsibilities will change within the public-private 
collaboration: 
= from ‘managing traffic and roads’ towards ‘supporting individual road users’ 
a dealing with the transition from ‘compliance/collective’ driven model(s) towards ‘user 
driven/centric’ model(s) 
= determining the optimal arrangement of roles for both public and private entities 


As a result, the vision does not just focus on technology or the traffic management process 
but is elaborated along four elements: 


e CUSTOMER 
Making the customer an active part of the Interactive Traffic Management: let him 
or her provide feedback and consider it. But also to provide specific information, 
guidelines and motivation regarding common traffic strategies concerning his journey. 
The customer should be convinced to recognise the benefit of the offered service; 
customers will however not actively be involved in the development itself; this will be 
achieved via the service providers. 

e COMMUNITY 
People can, as a group, have a certain impact on society/city with their travelling 
behaviour; by supporting these communities during their journeys, the alliance has an 
influence on the impact of the mobility of these people. 

e TECHNOLOGY 
Technology serves as a means to support the individual user, society/communities and 
the alliance; the project aims to combine technologies in a smart, user-centred way 
(balanced route optimisation, gamification, predictions). 

e COOPERATION 
Make the cooperation fit to impact driven business models. A key aspect is to define 
collaboration KPI's: how can be measured who contributed what to the common goals? 
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4.2. The four elements of SOCRATES2° 


The partners started with a kind of a ‘golden circle’ approach. Each elements was 
elaborated separately by addressing the following points: 


For each element it was made explicit why the partners support joint objectives. 
For each element the key questions to be answered by the pilots were identified. 
And for each element the main ideas (what) and underlying leading principles (how) 
were determined. 

The essence of each element is captured into four ‘slogans’, especially summarising 
what is new behind this concept, compared to contemporary traffic management. 


am, 





Figure 6: The framework of the shared vision of SOCRATES? 


4.2.1. Customer 





The focus of SOCRATES? is on road-related users, but not incorporation of all modes like 
public transport in use caseuse cases or pilots. The addressed road user in SOCRATES?” is 
limited to those users who can be reached by the communication channels and the specific 
use cases that are part of the pilots (e.g. partners’ app users, specific use case situation). 
The common picture of the customer is a road user who makes decisions based on his 
personal experiences and individual habits. The function of Traffic Management is to 
provide him or her with information and guidelines concerning his journey, but at the end 
the user is the one who makes decisions within the legal rules and is offered infrastructure 
and services. Thus, wanting him or her to behave according to traffic management goals 
(e.g. load balanced, safety and environmental aspects), he or she has to be informed about 
the what AND the why, to be motivated and to collect AND to consider his or her feedback. 
Note that this might change when automated driving really takes off. When level 4 and 
level 5 automation are introduced on a large scale the needs of the customer can undergo 
dramatic changes. The relevance of information directly targeted at human beings, might 
diminish. Instead of that automated messages that can be incorporated in the vehicles 
algorithms gain importance. 

The ‘language’ that is used by service providers to communicate with individual road users 
is expected to lead to improved understanding and adoption. As a result, people are more 
capable to decide for themselves (CEO!) while their decisions become more predictable. 
The consortium partners are combining a variety of communication channels: navigation 
systems, apps on smartphones, in-car equipment, social media platforms and roadside 
equipment. As a result, we are capable of reaching and supporting a much broader range 
of road users, and at different stages of the journey: pre-trip, on-trip and post-trip. This 
combination makes the influence on individual decision making more effective than today’s 
service provision. At the same time, it provides a better insight in what choices road users 
are about to do. This will help to predict the impact on traffic, on the network and on 
society and intervene appropriately. Eventually, this results in a WIN-WIN-WIN situation. 


Customer 


Slogan: CEO of my own journey 


Individual customer can make his own decisions; we provide him tools to support this 





Key questions: 


» What user groups should we focus on? And how do we maximize 
compliance by the road user? 

» What do customers use (and what not) and why (also related to the 
network characteristics and ITS smart facilities)? 

* To identify key indicators to assess user acceptance, satisfaction 
and impact on network performance 


+ On which situations/conditions can specific individual customers or 
user groups have an (higher) impact? 

+ How do we ensure clear, consistent and individually relevant distri- 
bution of information and advices to users? 


Main ideas: Principles/characteristics: 


* Find trip advice that suits me most 

» Ask me, challenge me, reward me 

» Let me provide feedback and share my experiences 

* Give me feedback/confirmation that | have made the right decisi- 
ons 

» Show me the impact of my trip 

» Let me indicate how detailed | want to be informed 
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+ Intuitive, effortless, hasslefree travelling for all modes: feels like 


being lucky & happy during the entire journey 


+ Meet and manage my road-related journey expectations 
+ | rely on my own car, personal devices, available transport modes, 


trusted/reliable information 


+ | make my choices at start of trip and on-trip 
* Stick to road traffic at this stage 


4.2.2. Community 





As a community a group of users is meant that have something in common and at the 
same time - as a group - have impact on society with their behaviour. A user can be 

part of different and also changing communities e.g. depending on his travel purpose, 
motivation of his trip, trip destination etcetera (e.g. commuter, car owner/shared mobility 
user, attendee of an event). The challenge is to cluster communities in the right way 
(target group), to find the right composition and to treat them differently. The clustering 
of communities can be different for each stakeholder. Public authorities may focus on 
how citizens can be persuaded into behaviour that is beneficial for society while service 
providers are interested in the motivation of its customers, but also visitors of a specific 
event to be able to deliver an attractive service. But the addressed community has be part 
of the collaboration and data exchange to come to a balanced strategy how to treat the 
different communities. Depending on the characteristic of the community (new) ways to 
communicate and to interact with them have to be found to reach a higher involvement. 
Offering feedback in kind describing contribution to social common goals (for instance 
safety awareness like avoiding schools and “footprint” like shared trips, saved kilometres, 
saved time, sum of followed recommended routes) could be a way to motivate user 
groups. For pre-trip choices the awareness of multi-modal information might be of 
importance to certain communities. 


Community 


Slogan: Choosing our mobility habits 


Seeking for a constant balance between what is good for the individual road user and what is good for society and encouraging individuals 
to behave responsibly: healthier, wealthier, wiser 





Key questions: 


* How can road operators utilise the intelligence of service + How will service providers deal with/communicate to customers 
providers to improve system optimisation? that the service may be suboptimal for the individual? 

* How can service providers include collective objectives in + How to define the value of driving behavior change for road 
individual user-oriented optimisation and communication? operators? 

» How do we measure the impact of individual decisions on society + How can we fairly optimise the system while addressing and 
and provide easy to understand and appealing feedback to preserving each community's interests? 
customers? + How can we fairly optimise the system while addressing and 

* What changes in travel/driving behavior result from providing this preserving each private business' interests? 


feedback to customers? 


Main ideas: Principles/characteristics: 
* Activate green awareness by providing a mobility footprint + Not just one community, composition changes all the time 
* Introduce positive incentives and pricing to change behavior + Groups to be treated differently: explain people what's behind it 
» Find balance between efficiency and comfort/users and + We all want to keep people/travelers safe 
environment + We want to experiment with new ways to communicate with 


citizens and to involve them 
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4.2.3. Technology 





The principle of SOCRATES?” is to use technology (= hardware, software and orgware) 
that is already available, but may not yet be used in the context of traffic management 
(e.g. social media). The SOCRATES?° partners bring in various technology expertise, e.g. in 
data exchange platforms, communication technologies, collaboration between roadside 
systems and in-car/on-person communication and social media communication. New in 
SOCRATES?? is to test new ways of collaboration which also implies the use of the existing 
technologies in new fields and combinations. 


Slogan: Facilitating the journey, unperceived 


Putting hardware, software and orgware in place to support customers optimally and reliably, as if it was always there 


Key questions: 


What data chains are to be established to deliver interactive traffic What maintenance conditions are imposed on the road network 
management? Examples for other domains? and roadside equipment? 

Who has access to what data, for what purposes/circumstances How to ensure that this platform for data exchange is open to 
and under what conditions? organisations that want to join? 

How will the required data flow change the internal working Consolidation: how and who to bring the data chains (not just the 
process of road operators? interfaces) to the market? How to reach scale? 

Interface to the customer: how to ensure that it is aligned? Technology develops faster than SOCRATES?": how to become 
How do we take care of privacy and security in the data chains flexible? 

arising? 


Main ideas: Principles/characteristics: 


Standardised interfaces, open platforms Substantial improvement by using new data sources thanks to 

Adopt technology that enables individuals to meet new technologies 

expectations, while fitting in services managed for groups within Try to be hardware agnostic: goal = optimal cooperation 

the community Intelligent use of what is already available: modular approach, 

KPIs for network performance & customer satisfaction e.g. set up data chain per use case instead of everything at once 
Public data open to all service providers 
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4.2.4. Cooperation 





The SOCRATES? project partners are motivated to collaborate. Not because it is inevitable, 
but really motivated to work together and to bridge the gap between the dimensions and 
create something new. The goal is to make the cooperation fit to impact driven business 
models: organisations have an interest to contribute to common goals because that is 
where there are rewarded for. A key aspect therefor is to define collaboration KPI's: how 
can be measured who contributed what to the common goals? 

However, we must be aware that different partners in SOCRATES have different goals. 
Serving the collective interest might be a common tool but the goals for the governments 
differ from the goals of the private partners involved. This poses a challenge on the 
collaboration: how can we make sure that the collaboration is in the interest of any party 
involved. Can the common good be served while in the mean time market differentiation 
allows different private partners to meet their business cases? This is one of the main 
challenges SOCRATES?” faces. 


Cooperation 


Slogan: Joint effort, shared benefit 


Everyone is rewarded for contributing to improved societal impact 





Key questions: 


+ What is the societal and commercial value of what we develop + How does the alliance perform on these key factors? 
together? Are the assumptions valid? + How do we cooperate with other, nearby and similar projects 

+ Customer in the loop: how to arrange this within the alliance? (to prevent reinventing the wheel)? 

+ What are the key factors determining success and scalability + How do we determine and create ‘impact’ and how is it 
(technologically, commercially, organisationally)? rewarded? 

Main ideas: Principles/characteristics: 

+ Making the alliance durably successful (collab. KPIs) * Desire to collaborate 

+ Impact driven solutions * Reciprocity with respect to data and information exchange 

+ Cooperation utilising each other's strengths to the full (equal » Making cooperation fit to impact driven business models 
partners) * Customers and community in the loop: feedback from users on 

+ Think big, act small (scrum) various topics, not just about the services 


+ Levels of transparency 
+ Exportable to future, other players and other areas 
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4.3. Conclusion 


The shared vision provides the main objectives, key research questions and leading 
principles on a strategic level. The vision is ambitious and gives guidance to define use 
cases and the scope of tests to be performed at the various pilot sites. The paradigm shift 
is needed to achieve real and successful interaction between customers (road users), 
private and public organisations in mobility. As such it really paves the way to future 
Interactive Traffic Management. 


The vision describes the desired future state, but the intermediate steps to get there are 
yet to be defined. To bring the vision to the pilots in the ongoing deployment work, it is 
productive to have the slogans as the agreed base: 


e Active involvement of the customer (road user) and the communities (pre-trip, on-trip 


and post-trip)! 
e Move from managing traffic to supporting individuals! 


Slogan 
“CEO of my journey” 


CUSTOMER 


SOCRATES?2° 


Y 
$ 
o 
+ 
3 
S 
3 
m 


shared benefit” 

COOPERATION 
ALINNWNOI 

«SHQUY Aypiqou 
4no Zu1sooy), 


TECHNOLOGY 


“Facilitating the 
journey, unperceived” 





Figure 7: The four elements of SOCRATES? and their slogans 
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5. USE CASES 
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5.1. Introduction 


The vision, as described in Chapter 4, sets the scene for the project. One the elements of 
the vision is that the road user should be in the centre of attention. This means that 'use 
cases’ are a logical next step in the process. A use case can be described as ‘a list of actions 
or event steps typically defining the interactions between an actor and a system to achieve 
a goal. The actor can be a human or other external system.” 


The following requirements needs to be fulfilled to create a valid use case: 


1. Ause case must describe the relevant stakeholder 

2. Ause case must provide value to a stakeholder > Goal orientation 

3. Ause case must be a complete narrative describing the story of how the value is 
provided > Must have main and alternative flows 

4, Ause case must stand alone > No sequencing of use cases 

5. Ause case must not describe system design > Describe “what” instead of “how” 


The project selected the following use cases in the proposal phase: 


Smart routing 

Actual speed and lane advices 

Local information and hazardous warnings 
Improved roadside traffic management measures 


A common feature of these four use cases is that they require the collaboration between 
traffic centres and (service provider) back offices based on an interactive use and 
dissemination of information and data. This leads to an approach in which traffic centres 
actually can influence, warn and advise road users (via the service providers) or self-driving 
vehicles (via the car industries) and the services delivered to end users are of improved 
quality (accurate, timely, rich individual and context-aware content), meaning: serves better 
their individual needs. 


SOCRATES?° cooperates among others with the C-Roads Platform, the European ITS 
Platform (EIP), the Traffic Management 2.0 platform and DATEX II community, especially 
on the functional design of the SOCRATES?” services. All four use cases of SOCRATES? are 
described as so-called “Day 1” or “Day 1.5" services. 

In this phase (Activity 2), a first elaboration of the use cases is done. Further specification 
will be done in subsequent phases. During Activity 2, it turned out that it made more sense 
to integrate the fourth use case (improved roadside traffic management measures) into 
the other three use cases. This proved to be an enabler for the other use cases. So this use 
case is not explicitly specified. 

This chapter includes a short summary of the use cases so far. In the appendix to this 
report, the complete use case can be read. 





7https://en.wikipedia.org/wiki/Use_case 
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5.2. Smart routing 





Summary 

Cooperation between road authorities and navigation service providers on the generation 
and transmission of ‘smart routes’ to improve traffic flow and efficiency and to provide 
more reliable navigation solutions for the road user. 


Background 

Conventionally, a route for a road user is determined by individually optimising the user's 
preferences; e.g. travel time/travelled distance. This information can be enriched with 
information such as real-time traffic information in order to determine estimated time of 
arrival more accurately. The information generation and route calculation is usually done 
by private companies. 


Road authorities would like to influence the use of certain routes by individual road users 
in order to reduce traffic congestion and emissions and increase traffic safety. Moreover, 
they have exclusive access to traffic information relevant for the route generation". 


A framework for better cooperation between public and private stakeholders to align on 
each other's priorities and needs is seen as beneficial for all stakeholders. 


Objective 
Bring together the road authorities’ needs and the navigation service providers’ tasks to 
provide ‘smart routes’ for road users to: 


e provide road users an enhanced travelling comfort and higher satisfaction; 

e offer fleet authorities /managers that apply a ‘smart route’ to a controlled vehicle a 
reliable travel time; 

e make sure roadside and in-car systems do not give conflicting advice to road users 
establish collaboration between public and private for future projects. However, 
this may not be a problem as long as the road user does not get confused by the 
information provided. For this, we need to understand what road users really need or 
use in given situations; 

e support road authorities to have a better outreach to road users and communities/ 
target groups; 

e use of the service providers knowledge on the needs and characteristics of their specific 
clients, communities/target groups in order to be able apply this to “optimal/smart 
routes” from the public perspective; 

e support road authorities to better monitor travel patterns and the acceptance of routing 
advices; 





18|n the Netherlands a lot of information is not exclusive to the road authority, but also provided as open data. However, the level 
of detail might be insufficient, the specific data might not be open and outside of the Netherlands this data might not be open. 
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e provide service providers with information on routing strategies within different road 
conditions and traffic situations and this way improve / expand service offer of service 
provider; 

e support road authorities to spread traffic through the network according to current or 
expected traffic and road conditions and route strategies. 


Expected benefits 

e Road users receive more and consistent information (what you see in the car is what 
you see on the road sign) to take informed decisions; 

e Road users arrive at their destination more satisfied, e.g. due to shorter travel times, 
higher comfort, lower costs etcetera; 

e Road authorities can better monitor travel patterns and acceptance of routing advices 
which helps to improve the effectiveness of the system; 

e Service providers benefit from satisfied customers (cities/and/or road users) due to 
better services compared to competitors; 

e Fleet managers improve their results; 

e Optimised traffic demand distribution leading to better traffic flow, less congestion and 
emissions and increase in quality of life. 


Sub use cases 
The following use cases within this category have been identified so far: 


1. Optimising network traffic flow 
2. Individual routing towards public event locations 


5.3. Actual speed and lane advices 


Summary 

The service provides speed and lane advice to road users in order to improve traffic safety 
and traffic flow efficiency and to reduce traffic emissions. Speed and lane advices could be 
mandatory. 


Background 

On roads that are equipped with a lane control system (LCS), road users are provided with 
actual speed and lane advices by dynamic traffic signs. This information could also be 
provided to the road user via an In-Vehicle Signage (IVS) service. 

On roads that are not equipped with a physical lane control system (LCS), a virtual LCS 
could be installed, providing the same type of information to road users via an In-Vehicle 
Signage (IVS) service. This IVS service is generated by service providers and should be 
aligned with speed and lane advices that are provided by road authorities. 
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Objective 

e Aligning speed & lane advices provided by service providers with the ones provided by 
road authorities; 

e Reinforcing the messages shown at the roadside by providing them in-car as well; 

e Expanding the reach of speed & lane advices towards places without roadside 
equipment; 

e Monitoring the follow-up behaviour of road users; e... Facilitating the driving task of road 
users by providing them with up-to-date in-vehicle information; 

e Minimising doubts regarding actual speed limits and lane situations (e.g. availability of 
hard shoulder running). 


Expected benefits 

e Improved traffic safety; 

e More attentive driving; 

e Increased driving comfort; 

e Preventing or reducing traffic accidents (i.e. rear-end collisions).Preventing or reducing 
congestion on roads; 

Improved traffic flow; 

Decreased traffic emissions; 

Higher reach of road users; 

Better insight in follow-up behaviour of road users. 


Sub use cases 
The following use cases within this category have been identified so far: 


. Maximum allowed speed 

. Speed advice “Congestion ahead” 

. Speed advice “Head of congestion” 

. Speed advice at traffic lights 

. Speed advice at shockwaves 

. Lane information 

. Lane advice at short on- and off-ramps 
. Lane advice at traffic lights 


CON dd Ub UN = 
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5.4. Local information and hazardous warnings 


Summary 

Local information and hazardous warnings' aim is to inform and warn vehicles on local 
situations and receiving feedback on the information from road users based on the current 
real world situation. 


Background 
This service has an informative and safety-related nature and also a user feedback 
response. 


Objective 
Warn and inform on upcoming road situations and mirror road signage and receive 
feedback on the provided data from road users. 


Expected benefits 
Reduction of avoidable incidents and generation of a higher level of detail within the 
available data set. 


Sub use cases 
The following use cases within this category have been identified so far: 


. Road works warning 

. Road condition warning 

. Emergency service protection 

. Environmental/Areal information and constraints 


BRWN = 
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6. STRATEGY 
COORDINATION 





6.1. Background 


In SOCRATES?, we want to discuss and describe future Traffic Management concepts, 
including cooperation between different road authorities and service providers / OEMs. 
Cooperation in this context is understood as the agreement on, and exchange of 

Traffic Management strategies. The strategy includes the vision that we are moving the 
perspective from managing traffic to supporting the decision making of individual drivers, 
and putting the end-user in the loop. 


As explained before in this report, future concepts for cooperation in the field of Traffic 
Management have been already discussed within other platforms. 

The working group “Enhanced Traffic Management” of the C-ITS Platform’? envisions that 
traffic operations can be heavily optimised with the potential of increasing connectivity and 
automation. For this, “Pan-European Cooperative Traffic Management Services” need to be 
deployed. 

The working group has also investigated how such Cooperative Traffic Management may 
be put into operation, looking at an example of incident management. 


In the current situation (left figure below), a service provider would recommend the 
alternative route “B” when an accident happens, as it is the shortest and fastest path, 
resulting in travel patterns through non-desirable road network elements (urban 
neighbourhood). 

In an ideal situation (right figure below), the road authority and service provider coordinate 
their activities to achieve an overall higher network performance with increased safety and 
reduced congestion time. 





Figure 8: Re-routing with Cooperative Traffic Management (left: current situation; right: ideal situation) 
Source: C-ITS Platform, 2017. Draft Final report Phase II 





18 C-ITS Platform, 2017. Draft Final report Phase Il. 
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In this example, both stakeholders take actions which complement each other, leading to 
a win-win situation for everyone. This example also shows the cooperation efforts by both 
actors, i.e. the definition and alignment of complementary measures, and the consistent 
communication towards the road user. 

In this context, the working group has emphasized the need for the collaboration and 
dialogue between stakeholders”. It has identified three key topics for such a dialogue: 


1. The data categories and the exchange requirements for establishing the dialogue; 
2. The governance model in which the dialogue can be established; 
3. The means for establishing the dialogue. 


Further perspectives on these matters have been elaborated by the TM2.0 platform, 
particularly its taskforce on Traffic Management Plan (TMP) Exchange?',”?. 

TM2.0 sees mutual benefits for both road authorities and service providers when TMP's 
are exchanged. TM2.0 also aims to overcome current difficulties due to heterogeneous 
data availability and quality across Europe, and to utilise new possibilities due to 
increased connectivity, use of in-car services and improvements in Traffic Management 
infrastructure. 

The TM2.0 taskforce has developed a concept of TMP's (including decisions, procedures 
and strategies) and ideas how to exchange them in practice. This concept is mainly 
referring to Smart Routing, with the idea that individual route advice may be optimised by 
cross-checking and cross-fertilising with TMP’s, eventually creating better advice to road 
users and enabling user feedback to TMC's. In addition, TM2.0 has formulated applicable 
use cases, recommendations and guidelines for involved stakeholders, with the goal of a 
“European TM2.0 Ecosystem”. 

One essential recommendation is that the two main groups of stakeholders (road 
authorities and service providers) have to understand and respect each other's interests 
and translate Traffic Management Strategies into measures taken by both. 


To discuss and identify suitable cooperation frameworks for future traffic management, 
with a particular focus for SOCRATES2°, a dedicated Focus Group “Strategies and 
Cooperation” was set up within Activity 2 (FG3). The key questions of this group were: 


What is a strategy at all? 

How to ensure continuity from policy to operational level? 

How to develop & decide on optimal and common strategies? 

How to combine/prioritise (conflicting) strategies? 

How to experiment with different roles / to play with responsibilities? 

How to address both public and private needs, including competition of service 
providers? 





20C-ITS Platform, 2017. Draft Final report Phase Il. 

21 Spoelstra, J., van Waes, F., Mann, M., Kontantinopoulou, L., Dr. Tzanidaki, J., 2017. Exchanging Traffic Management Plans data 
between Traffic Management Centres and Service Providers in Traffic Management 2.0. 12th ITS European Congress, June 2017, 
Paper no. TP0809. 

2Rodrigues, N., Spoelstra, J., Sykora, R., van Waes, F., Dirnwoeber, M., Kontantinopoulou, L., Dr. Tzanidaki, J., 2016. The exchange 
of traffic management plans in TM2.0. 11th ITS European Congress, June 2016, Paper no. ITS-EUTPO199. 
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The lower set of these key questions can be summarised into this fundamental question: 
“How do we want to organise cooperation between each other?” The Focus Group elaborated 
these questions based on internal and external expert knowledge as well as intense 
discussions among project partners. 


6.2. Definitions 


As a first approach towards the topic, different perspectives on the term “Traffic 
Management strategy” were discussed. The following figure shows, how one may look at 
strategy. 


BY LAYERS BY PROCESSES 


BY CHARACTERISTICS 


Objective / Target BY TYPE OR TOOLS 


Action / Measure 
BY ACTORS 





Figure 9: Different ways to look at Traffic Management Strategy 


The most important parameters were identified in the “Layers” definition, with three layers 
of Traffic Management from policy to operational level. A detailed definition on these three 
layers can be found at TM2.0?: 


e Ona strategic layer, policies are decided e.g. regarding the priority of traffic flow in the 
network. 

e Ona tactical layer, the situation in the network is described, bottlenecks are analysed 
and measures are identified to resolve the bottlenecks. A Traffic Management Plan is a 
set of measures, such as traffic flow control, rerouting etc. 

e On the operational layer, Traffic Management Plans are executed by sending out 
messages/instructions to road users, either via roadside equipment or via in-car or via 
personal communication devices. 


The Focus Group concluded that the idea of a Traffic Management strategy not only applies 
to an operational TM measure, but also includes higher-level and tactical levels. Thus, 

any strategy and coordination concept within SOCRATES? has to consider those multiple 
dimensions, in order to ensure continuity of Traffic Management throughout the layers. 





2Spoelstra, J., van Waes, F., Mann, M., Kontantinopoulou, L., Dr. Tzanidaki, J., 2017. Exchanging Traffic Management Plans data 
between Traffic Management Centres and Service Providers in Traffic Management 2.0. 12th ITS European Congress, June 2017, 
Paper no. TP0809. 
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Besides the definition of a Traffic Management strategy, further definitions are necessary 
to describe related stakeholders, roles, actors, processes and actions. 


Relevant stakeholders already have been identified and assessed under the “Stakeholder 
needs” (see Chapter 3). Another definition on stakeholders, with a special focus on 
Cooperative Traffic Management, has been made by TM2.0: 


Road Infrastructure Owners 
Roadside Service Providers 
Content Service Providers 
In-car Service Providers 
Service Consumers 


For the matter of Cooperative Traffic Management, it is also necessary to differentiate 
between roles and actors, which can be defined with a role-model approach as follows?”*: 


e Actor: an organisational entity / institution that is capable of performing behaviour; 

e Role: responsibility for performing specific behaviour, to which an actor can be assigned. 
It can be considered as a set of actions. The bundling of actions to a role is determined 
by a given objective; 

e Action/process: defined as a behaviour element that groups behaviour, based on an 
ordering of activities. It is intended to produce a defined set of products or business 
services. 


While actors may be identically defined as in the definitions before, roles are not bound 

to a specific institution/organisation. Roles in this context may be service provision, traffic 
light control, technology provision, intermediary, service usage etcetera. Roles may be 
assigned differently depending on the cooperation concept and the specific deployment. 
The actions/processes, as introduced in the role-model approach above, will also depend 
on the individual cooperation concept and deployment, so no comprehensive definition 
can be made here. 

However, a generic categorisation of related processes has been made by TM2.0, described 
as three phases for the collaboration between stakeholders: 


e TMP elaboration phase: management tasks of involved stakeholders; preparation 
and combination of services, agreement upon a common understanding between 
stakeholders; 

e TMP operation phase: execution of a Traffic Management Plan; 

e TMP evaluation phase: recurrent analyses of impacts and, if necessary, revisions of 
measures; eventually improving the original Traffic Management Plan. 





4The Open Group, 2012-2013. ArchiMate® 2.1 Specification. 
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6.3. Cooperation Models 


In order to answer the above-mentioned question “How do we want to organise 
cooperation between each other?”, a higher-level debate was led by the Focus Group, 
looking at the goals of future Traffic Management in general, as well as at the requirements 
and assets of individual partners. 

To structure this debate, different Cooperation Models were introduced and discussed. 
These Cooperation Models were defined in the form of a matrix, looking at two dimensions 
regarding the exchange of Traffic Management strategies: 


e 1. Level of commonality 


No common - Co-creating 
A each other 1 ARO agreed ‘truth’ 


SS 
CCE AA EE 
pa 
EXA A E 










© 2. Level of detail 






Figure 10: Cooperation Model Matrix 
The two dimensions of this matrix are explained as follows: 


1. Level of commonality 

Question: Is there a commonly agreed plan/basis? 

Options: 

1. ‘Informing each other’ means exchanging information to allow organisations to 
enrich their own information with the information of others, enabling the possibility to 
anticipate on each other's actions and decisions, without the existence of a commonly 
agreed plan. 
> | know what others do/want and can anticipate on it, but we do not have a common 
basis/plan that | follow with my actions. 

2. ‘Co-creating a commonly agreed truth’ means exchanging information to co-create 
one commonly agreed basis that is the basis for individual actions/decisions. 
> We have a common and agreed basis/plan, that | follow with my actions. 


2. Level of detail 
Question: At what level of detail do we exchange? 
Options”: 
a) Situational - exchanging / agreeing on the status/situation of the network 
For example: sensors (FCD, air quality, sound levels, traffic volumes, etcetera), 
actuators (VMS text, active signs, traffic lights, warnings etcetera) 





25The four options correspond to the three “layers” of Traffic Management, as described above, plus the “situational” layer with a 
pure focus on information handling 
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b) Operational - exchange / agreeing on the measures/actions of actors 
For example: Changed rules in traffic lights, activated triggers, TM scenarios in place 
c) Tactical - exchange / agreeing on the targeted service levels (8 motivation) behind 
measures 
For example: Upgraded / downgraded in-flow or out-flow (as basis for changed rules 
in traffic lights), motivation behind TM scenario / VMS text 
d) Strategic - exchange / agreeing on goals/objectives, boundaries, and priorities, 
behind service levels 
For example: KPI on high level network performance, priorities between KPI’s (policy 
goals), minimum performances (limits) 


The matrix could be expanded to a third dimension, talking about the level of commitment 
of the individual actors. 


No common - A i , 
Informing each other Co-creating 1 commonly agreed “truth 


Free - No obligation | Free - No obligation | Commited - Obligation 


| BE BEE 
ea I 
a AA 
TT 





Figure 11: Expanded Cooperation Model matrix 


3. Level of commitment 

Question: Are actors free to use the agreed plan/basis? 

Options: 

a) Free/No obligation - Actors are free to use/ignore the common information as a 
basis for their measures. 
For example: A suggested route advice that is shared, but there is no obligation to 
show it to road user. There might be KPI’s indicating a contribution of measures 
to policy goals, but one is not obliged to use it in calculating route advice. Further, 
incentives can be organised to encourage the use of (common) information. 

b) Committed / obligation - The commonly agreed plan/picture has to be used as a 
basis for individual measures. 
For example: common (predicted) situational picture of traffic demand that have to 
be used in calculating routing advice, or KPI limits (representing for example policy 
objective) that have to be used in calculating routing advice, or a route advice or 
hazard warning that has to be given when certain conditions are met. 
Legislation can be implemented to enforce the use of (common) information. 
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The different options on the vertical side of the matrix may be visually explained as follows: 


No common - Co-creating 
informing each other 1 commonly agreed ‘truth’ 


Dx 


Figure 12: Visual explanation of Cooperation Models 





First discussions within the Focus Group on the interpretation and a potential preference 
of the many options made obvious that there will be no “one size fits all" Cooperation 
Model. In contrast, it is expected the selection of a “right” Cooperation Model depends 
on individual criteria, such as the applied use case, technical and economic feasibilities, 
existing governance rules, geographic characteristics etc. 


Further, it is expected that different models will require different data sets to be 
exchanged, different intermediary services, different agreements and possibly different 
business models etcetera. 


However, the concept of Cooperation Models, as introduced above, should give partners 
some orientation on the many options and their implications, helping them find the “right” 
Cooperation Models when specifying individual deployments. It is also recommended, that 
the upcoming SOCRATES?? pilots experiment with different Cooperation Models, so we get 
more experiences and lessons learned. 


To identify some first preferences on the Cooperation Models, the concept above was 
presented to all SOCRATES?” partners, asking for feedback on the following questions: 


e On what level does your organisation require/prefer to coordinate with others? 

e To coordinate on this level/these levels: what needs to be commonly agreed, and what 
can be done by informing? 

e What level of freedom/commitment/obligation do you require/prefer? 


54 


Referring to the use case “Smart Routing”, SOCRATES? partners were asked to: 


e describe pros/cons, expected benefits/concerns and questions on each of the 
Cooperation Models; 

e identify the most interesting scenario to be tested for use case Smart Routing; 

e share considerations on the level of freedom, and; 

e identify research questions for the preferred scenario. 


Feedback was received from eight partners. Based on analyses of this feedback, individual 
perspectives on the Cooperation Models show some commonalities, as summarised below. 
(The comments with + show expected pro's/expected benefits. The comments with - show 
cons/expected concerns). 


CEN Informing each other Co-creating 1 common ‘truth’ 


Situational + Transparent and factual - Who defines and handles the 
+ Better situational picture common ‘truth’ 
- No intelligence used form other - difficult data fusion 
actors - universal commitments may impede 
- Redundant data handling at each individual business models 
actor 


- How to access (sensitive) SP 
information? 
- Not suitable for 'advanced' Use Cases 


Operational - possible contradictory measures by + perfect alignment of TMCs and SPs 
different actors + all ‘channels’ to travelers used 
- not sure which information to - difficult to find consensus 
communicate from SPs to TMCs - take away freedom of actors 
Tactical + improve user acceptance when + common commitment on higher-level 
tactical or strategic information is + higher impact with common targets 
communicated or KPIs 
- Not sure which information to + flexibility and competition for actors 
communicate from SPs to TMCs - no guarantee that compatible 
Strategic measures are followed by all actors 
- difficult to describe commonly 
accepted targets, KPIs and methods 
- difficult scaling (e.g. for different 
government levels) 


Figure 13: Commonalities from partner feedback on Cooperation Models 





There is also a first consensus towards a set of preferred Cooperation Models (see below) 
as a scoring of individual preferences (each number represents how often a Cooperation 
Model was selected for a preferred scenario; a selection of multiple models was allowed). 


Tactical 


Figure 14: Scoring of preferred Cooperation Models, referring to the use case “Smart Routing”, based on partner feedback 
(numbers represent how often a Cooperation Model was selected; selection of multiple models was allowed) 
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As a tendency, the “Informing each other” concept is preferred for the situational and the 
operational levels. The “Co-creating 1 common ‘truth” concept is preferred for the tactical 
and strategic levels. 


While a “common ‘truth” approach could be a threat to the business model of partners 

at the situational and operational levels, clear benefits are seen at the tactic and strategic 
levels, when targets and KPI's are shared and aligned with each other. This is seen as a 
clearly innovative concept to be tested in SOCRATES?*. The stakeholders could discuss if it 
is necessary and possible to co-create on an operational and situational level as well as a 
result of collaboration on the strategic and tactical levels. 


However, procedure and services need to be designed to enable such a target/KPI 


exchange and alignment. This has a relevance to the set-up of the SOCRATES?” pilot sites, 
particularly of the potential intermediaries. 


6.4. Conclusions 


The Focus Group has consolidated some important conclusions, especially to be 
considered in the upcoming SOCRATES?” activities, such as the design and planning of the 
pilots: 


e When defining strategies and how to exchange them, all levels of Traffic Management 
(strategic, tactical, operational) have to be considered, to ensure continuity from policy 
to operational level, 

e Actors, roles and processes need to be clearly defined for all involved parties in 
Traffic Management. However, roles and actors may change among different (pilot) 
deployments. 

e For Cooperation Models, there is no “one size fits all”. In contrast, individual 
characteristics of a deployment have to be considered. Some preferences towards 
Cooperation Models could be identified, which should be tested at the SOCRATES?°. 


Research questions, as identified during the Cooperation Model discussion, have to be 
considered and evaluated at the upcoming pilots. 
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7. INTERMEDIARY AND 
DATA FUSION 


SOCRATES?20 





7.1. Introduction 


The various use cases and coordination models described in the previous chapters each 
ask for certain roles to be fulfilled by stakeholders. In this chapter, we explore the options 
for an ‘intermediary’. This role has been initially described as a facilitator for the interaction 
between public traffic centres and private back-offices. 


The Focus Group 2 presents a number of intermediary options in this chapter, for further 
discussion in the continuation of the project. For instance, the pros and cons of each option 
should be explored in the context of the applied cooperation model and use case. These 
options were chosen because they are clearly different in nature and show the width of 
options. Options chosen to be deployed in the pilot sites could still be variations on these 
options. 


In the options, a number of governments and their Traffic Management Centres (TMC) 
are present, as well as a couple of service providers (SP). Each TMC and SP has their own 
communication channels (measure actuation) towards the road users. 


For each option, roles like legal/privacy, business/contracting, standardisation and 
organisation are also necessary but are left out of the pictures to keep it a bit simpler. 


7.2. Different levels of complexity 


While describing the expected interaction between several public TMC and several private 
service providers the following levels of complexity were identified. 


1. Data exchange 
a. Provide data - receive data between public-public, public-private and private-private 
b. Use and handling of public and private owned data while assuring all parties 
interests 
2. KPI Monitoring 
a. Understand government goals and strategies vs. user needs served by private 
services 
b. Transparency on impact of private services towards public goals and vice versa 
3. Identification of win-win-win value case 
a. Insight into business and societal value 
b. New business cases development 
c. Quantification of win - win - win (Public - Private - Road user) 
d. Alignment between services and needs 
4. Orchestration of cooperation 
a. Development of common optimum as information (or mandatory) 
b. Publishing win - win - win value case 
c. Orchestrate measures and coordination between involved organizations; 
Commitment and engagement of public and private parties 
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5. Settlement of cooperation/interaction 
a. Liability, administration, clearing, settlement/integrity 
b. Demonstrate and validate value 


An intermediary (or a group of) can support or deliver a solution for overcoming these 
initially identified complexities and challenges for each type of cooperation model. 


7.3. Functions 


We distinguish the following (possible) functions that an intermediary could provide. By 
analysing National Access Points some functions (listed below) were identified and can be 
used as indications. 


Possible sub functions 


Data sensor Collection 
(Raw data) Distribution 
Aggregation 
Aggregated (Processed) data | Completion / imputation 
Fusion 
Analytics (historic) 
Quality Assessment 
(ist Control / audit 
Optimal routing Common Situational Picture - State of network 


(Traffic management) Common Predicted Situational Picture - Future state of network 


Common KPI picture - Calculation KPI on policy goals on vital 
elements 


Common Desirable Picture - Optimisation /negotiation/balancing/ 
validation 


Common DELTA picture - Difference CDP and CPSP 
Translation to measures - for Navigation routing and RS measures 


Actuation/Measures 


Routing services operation: navigation and roadside 
Feedback loop - Measures to CPS 
Organisational / Exchange Access to data (exchange) 

Access to services 

Interfacing back ends 
Business / Contracting Service value case developme 
Marketplace for impact driven services 
Reward/billing 
Coordination 
SLA management 
Privacy 
Security 


Terms and conditions 


Consent management 
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7.4. Intermediary Options 


The following options for an intermediary role related to a Smart routing use case were 
studied at this stage of the project. 

Depending on the different use cases and stakeholders, combinations of intermediary 
options presented below may be relevant. The discussion of advantages and disadvantages 
per option will be done in Activity 3. This will cover the specific situations in the pilot sites 
including regional boundary constraints, options and use case specific requirements. 


No intermediary 


Aggregated Aggregation Optimal routing Measure 
data Fusion Quality algorithm 


actuation 


Loop VMS 
data 


Traffic 
light 
status 


VMS 
status 





In this option, no intermediary is established. Each Traffic Management Centre and Service 
Provider arranges their own connection to the others. Each TMC and SP determines its own 
service optimum considering the given traffic situation. There is no common and agreed 
truth. 
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Multiple intermediaries for data aggregation - Informing each other 


Aggregated Aggregation Optimal routing Measure 
data Fusion Quality algorithm 


actuation 


Loop VMS 
data 


Traffic 
light 
status 


VMS 
status 





In this option, multiple intermediaries offering data aggregation services are present, there 
is competition. Each Traffic Management Centre and Service Provider can decide which 
intermediary service it wishes to subscribe to. Each TMC and SP determines its own optimal 
routing for the users. The intermediaries may be 1 public organisation and multiple private 
organisations. 
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1 intermediary for governments for aggregation & coordination - No intermediary 
for service providers 


Aggregated Aggregation R 
data Fusion Quality Measure actuation 


Optimal routing 


algorithm 
Loop 
data 


Traffic 
light 
status 


VMS 
status 


Aggregation 


Measure 


algorithm 





In this option, 1 intermediary is established for governments while the Service Providers 
do not have a dedicated intermediary, although data is shared back and forth. The 
government Traffic Management Centres use the intermediary to align on Traffic 
Management Plans and actuation of Traffic Management measures. The Service Providers 
do operate independently from each other. 


62 


1 distributed intermediary for aggregation and coordination; - ‘Common truth’, 
‘Trusted Entity’ 


Aggregated Aggregation A 
data Fusion Quality Measure actuation 


Optimal routing 


algorithm 
Loop 
data 


Traffic 
light 
status 


VMS 
status 


Intermediary 





In this option an intermediary framework is established that allows the trustful 
cooperation between stakeholders. The tasks of the intermediary can be fulfilled by several 
stakeholders. Introducing the concept of a trusted entity will allow even cooperation 
between competing parties aiming for a common truth and agreed system behaviour. 
Each Traffic Management Centre and Service Provider will act as an integrated part of the 
intermediary. 
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1 single intermediary for aggregation & coordination - ‘Orchestration’, 
‘Centralised System’ 


Aggregated Aggregation A 
data Fusion Quality Measure actuation 


Optimal routing 


algorithm 
Loop 
data 


Traffic 
light 
status 


VMS 
status 


Miermediary 





In this option only one intermediary is established. Each Traffic Management Centre 
and Service Provider is connected to the intermediary. The task of the intermediary is to 
generate common truth and provide instructions to all parties for their system behaviour. 
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8. BOTTLENECKS 
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SOCRATES? paves the way for the next generation of traffic management. On this way, 
there are several challenges, impediments, or generally speaking, bottlenecks. 
Bottlenecks may slow down or even hinder some of the envisioned goals. They may affect 
any Traffic Management solutions during their preparations or during their deployment, 
either in pilot sites or in a European roll-out. Bottlenecks may also differ depending on the 
type of use case or local conditions. 


Some bottlenecks have been already addressed in other projects. Some other bottlenecks 
have been specifically identified within SOCRATES°. The following chapter aims to give 

an overview on relevant bottlenecks and their relevance to the topic “Interactive Traffic 
Management”, generally, or to SOCRATES**, specifically. 


Regarding possible solutions, there is no explicit aim to solve all the bottlenecks - that 

is far beyond its scope - but SOCRATES? will identify possible approaches for occurring 
bottlenecks during deployment of the concept in the four pilot sites. The project may 
also identify needed higher-level actions outside of the scope of this project, for instance 
on legislation or standardisation, and motivate related institutions to work out suitable 
solutions. 


One of the main sources for this chapter is the TM2.0 report on enablers and barriers”. 
The bottlenecks have been clustered into the following categories. This is again based on 
TM2.0. However, a “data” category has been added, as many bottlenecks are related to this. 


Data bottlenecks 

Technical bottlenecks 
Organisational bottlenecks 
Business-related bottlenecks 
Legal bottlenecks 
Conceptual bottlenecks 


The bottlenecks are described in the form of structured templates, including the following 
entries: 


Name 

Description 

Source 

Effect on (e.g. which element of SOCRATES?°?) 

Risks when not solved 

Responsible stakeholder (which body should take care of this?) 
Already addressed (e.g. other projects) 

Possible solutions 





6 Traffic Management 2.0 (TM2.0), 2015. Report of the Task Force 2 on Enablers and barriers, January 2015. 
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Based on current analyses, there are 17 bottlenecks in total. Some of them have a current 
relevance for SOCRATES?, i.e. they have been explicitly discussed in the SOCRATES?° 
project so far. However, it is expected that the other listed bottlenecks will be also relevant 
during later stages of the project. It is also possible that further bottlenecks will be added 
later. 


It is suggested that the following elaboration is considered a “living document”, to be 
completed or amended during the project runtime. 


8.1. Data bottlenecks 


1: Lack of accessibility to data 


[Description] Many use cases of Interactive Traffic Management rely on data sources that are in 
the domain of various stakeholders. It is important to raise awareness to stakeholders to open 
up their data sources to external partners as much as possible, respecting everyone's business- 
models, assets and privacy. 


[Source] FG4 (see Chapter 6) 

[Effect on] Interoperable utilisation of any data within Interactive Traffic Management 

[Danger when not solved] Domain-based data cannot be communicated between stakeholders. 
Basic goals of Interactive Traffic Management are not met. 

[Concerned stakeholder] Developers of Interactive Traffic Management 

[Already addressed] On-going high-level discussions on openness of data, e.g. the ‘Data Task 
Force’ with governments and car manufacturers aiming to reach agreements. Regarding specific 


data requirements, a “data landscape” for potential use cases was elaborated in FG4. Further, the 
upcoming designs of SOCRATES?” pilots will specify data provision from individual partners. 
[Possible solutions] Proven data-sharing models from previous projects. Point of attention is that 
necessary agreements on data provision between stakeholders in the traffic management chain 
may not comply with the legal framework for open data. 


2: Lack of standardisation for Traffic Management Plan data 


[Description] Traffic Management Plans (TMP's) have to be exchangeable between different 
actors. TMP's may be very different from case to case, and include complex contents. Only limited 
standards for interoperable data models and interfaces for TMP's exist. 


[Source] FG3; TM2.0 
[Effect on] Interoperable utilisation of TMP data within Interactive Traffic Management 


[Danger when not solved] TMP's cannot be communicated between stakeholders. Basic goals of 
Interactive Traffic Management are not met. 


[Concerned stakeholder] Standardisation bodies; traffic information service providers 
[Already addressed] A DATEX II extension was developed for the use case “strategic routing” in the 
project LENAAITS?”, 


[Possible solutions] Further standardisation of TMP data models and interfaces. A specific 
interface will be realised in SOCRATES”? (“TMex”). 








7 bast.opus.hbz-nrw.de/volltexte/2015/1625/pdf/F108_barrierefreies_Internet_PDF.pdf 


67 


3: Lack of standardisation for vehicle probe data 


[Description] Standards for vehicle probe data are not finalised, or are not consistent to each 
other. 


[Source] TM2.0 
[Effect on] Interoperable utilisation of vehicle probe data within Interactive Traffic Management 


[Danger when not solved] Vehicle probe data cannot be communicated between stakeholders. 
Basic goals of Interactive Traffic Management are not met. 


[Concerned stakeholder] Standardisation bodies; OEM industry 
[Already addressed] On-going standardisation activities, e.g. at ETSI?® 
[Possible solutions] Further standardisation of vehicle probe data 


4: Lack of interoperable maps and georeferencing methods 


[Description] Existing maps and georeferencing methods differ among different stakeholders and 
among use cases. 


[Source] TM2.0 
[Effect on] Interoperable utilisation of any spatial data within Interactive Traffic Management 


[Danger when not solved] Spatial data cannot be communicated between stakeholders. Basic 
goals of Interactive Traffic Management are not met. 


[Concerned stakeholder] Standardisation bodies; traffic information service providers 
[Already addressed] On-going guidance, specification and standardisation activities at TN-ITS?° 
[Possible solutions] Increased use of state-of-the-art georeferencing methods enabling data 
exchange and cross-referencing between stakeholders, e.g. OpenLR*° 

5: Lack of security infrastructure for Cooperative Vehicle Data 


[Description] A security infrastructure, assuring integrity and privacy of vehicle data, has been 
proposed by C-ITS stakeholders, but is not in place yet. 


[Source] TM2.0 


[Effect on] Interoperable utilisation of Cooperative Vehicle Data within Interactive Traffic 
Management 


[Danger when not solved] Security threats resulting in malfunctions or lowered user acceptance 


[Concerned stakeholder] C-ITS stakeholders, e.g. at the Amsterdam Group?! 


[Already addressed] On-going deployment activities for C-ITS, e.g. at C-ROADS?2 





[Possible solutions] Proposal for a “Public Key Infrastructure” 





2 www.etsi.org/technologies-clusters/technologies/automotive-intelligent-transport 
2 http://tn-its.eu/ 

30 http://www.openlr.org/ 

31 amsterdamgroup.mett.nl/default.aspx 

32 www.c-roads.eu/platform/activities/wg-technical-aspects.html 
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6: Lack of common data formats for intermodal traffic information 


[Description] Intermodality will be part of many use cases of Interactive Traffic Management. 
However, there are only limited common data formats and interfaces for intermodal traffic 
information, crossing different modes, countries and operators. 


[Source] TM2.0 

[Effect on] Deployment of services including intermodal traffic information 

[Danger when not solved] Lacking information to road users on all available traffic modes 
[Concerned stakeholder] Stakeholders of intermodal traffic information 


[Already addressed] On-going efforts to establish National Access Points for intermodal traffic 
information, in accordance to Commission Delegated Regulation (EU) 2017/1926 


[Possible solutions] Data hubs for the integration of regional public transport information, e.g. 
DELFI?* 


7: Insufficient or unclear quality of exchanged data 


[Description] When acquiring data from external parties, it is not always clear if the data meet the 
requirements of the data user. Quality of data is rarely systematically assessed and transparently 
documented. 


[Source] TM2.0 
[Effect on] Reliability and safety of related services of Interactive Traffic Management 


[Danger when not solved] System malfunctions; erroneous information to the road user; lowered 
user acceptance 


[Concerned stakeholder] Data providers 


[Already addressed] Quality assessment concepts in the field of traffic information, e.g. the QKZ- 
method?*; Quality frameworks for various ITS data types on EU level, e.g. in EU ElP* 


[Possible solutions] Proven quality assessment procedures from previous projects 








33 eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R1926 

34 www.delfi.de/ 

35 https://doi.org/10.1016/j.sbspro.2012.09.809 

36 eip.its-platform.eu/activities/sa-41-determining-quality-european-its-sevices 
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8.2. Technical bottlenecks 


8: Lack of compatibility with TMC legacy systems 


[Description] Existing TMC’s need to be enhanced regarding communication, interfaces, data/ 
information processing etcetera in correlation with external actors. However, older systems do not 
always allow such scalability / interoperability. 


[Source] TM2.0 


[Effect on] Europe-wide roll-out of Interactive Traffic Management. (For pilot projects, such as 
SOCRATES?®, this may not be a problem, as solutions are usually worked out within the project 
frame.) 


[Danger when not solved] When working with existing systems: functionalities of Interactive 
Traffic Management are limited; when building new systems: possible redundancies (parallel “old” 
and “new” systems) 


[Concerned stakeholder] TMC operators; financing bodies behind TMC's 

[Already addressed] Pilot projects with an operational trial, e.g. NAVIGAR?” 

[Possible solutions] Provide technical and financial support to upgrade/redesign/migrate existing 
TMC's. 

9: Insufficient penetration of vehicles and compatible TMC's 

[Description] Long transition periods towards a critical mass of integrated vehicles and TMC's 
[Source] TM2.0 

[Effect on] Measurable, large-scale benefits of Interactive Traffic Management 


[Danger when not solved] Effects of Interactive Traffic Management will be only on limited 
number of road users. 


[Concerned stakeholder] Governments and industry 


[Already addressed] SOCRATES?? pilot sites will have a significant number of participating road 
users. 


[Possible solutions] Roll-out on a large scale; promotion of products on the vendor-side; 
investments into TMC upgrades (see Bottleneck no.1) 
10: Insufficient cellular communication networks 


[Description] Services based on cellular communication require full availability and quality of the 
network coverage. 


[Source] TM2.0 

[Effect on] Functionality of services based on cellular communication 

[Danger when not solved] Services are spatially/temporarily not available. 

[Concerned stakeholder] Telecommunication industry, governments 

[Already addressed] several initiatives by telecommunication industry, governments 
[Possible solutions] Improvements towards availability and quality of the network coverage. 








37 www.its-bw.de/navigar 
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11: Lack of advanced Traffic Management algorithms 


[Description] Existing TMC's are mainly isolated systems, including proprietary sensors and 
actuators, and (automated) algorithms triggering Traffic Management measures. For Interactive 
Traffic Management, with many more sensors and actuators, these algorithms have to be re- 
designed and re-validated. 


[Source] BASt 

[Effect on] Efficiency of measures in Interactive Traffic Management 

[Danger when not solved] Envisioned goals (e.g. for traffic flow) cannot be met. 
[Concerned stakeholder] TMC operators, research organisations 

[Already addressed] On-going research project at BASt 

[Possible solutions] Re-design of existing algorithms 


8.3. Organisational bottlenecks 


12: Non consensus on cooperation models 





[Description] A viable cooperation model has to be clearly defined and accepted among partners 
for each deployment of Interactive Traffic Management. During first discussions in FG3, it became 
clear that it is not ease to find a “right” cooperation model. 


[Source] FG3 

[Effect on] Deployment of Interactive Traffic Management with added value for each partner 
[Danger when not solved] No sustainability of deployment (e.g. partners may leave the project) 
[Concerned stakeholder] Developers of Interactive Traffic Management 


[Already addressed] Different cooperation models have been discussed in FG3, including what 
models may be preferred. The upcoming SOCRATES? pilots will test different cooperation models, 
which then will be evaluated. Further conclusion will be given at the end of the project. 





[Possible solutions] Proven cooperation models from previous projects 


8.4. Business-related bottlenecks 


13: No clear return of investment for actors 

[Description] Any investments in technical infrastructure (e.g. upgrades of TMC's) and provision 
of data and/or information (e.g. traffic flow data from service providers) need an economic 
justification. This has not been proven on a large scale. 

[Source] FG3; TM2.0 

[Effect on] Technical infrastructure; provision of data flows between actors 


[Danger when not solved] Traffic Management data cannot be communicated between 
stakeholders. Basic goals of Interactive Traffic Management are not met. 


[Concerned stakeholder] Developers of Interactive Traffic Management 


[Already addressed] Discussion of “impact-driven business models” as part of the cooperation 
models. The upcoming design of SOCRATES?” pilots will include decisions on cooperation models 
and if any financial transactions (or other arrangements) are involved. 


[Possible solutions] Proven business models from previous projects. Nationwide fiscal incentives 
could be considered. Assess possible investments in TMC's not just in the light of its own 
operational objectives, but take the wider policy goals in account as well (with financial support 
from the policy makers if possible). 
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8.5. Legal bottlenecks 


14: Unsolved privacy concerns 


[Description] Services involving sensitive personal data (e.g. origin/destination information) need 
to comply with privacy legislations. Such data is subject to EU national laws, specifically laws 
transposing EU Directives. 


[Source] TM2.0 
[Effect on] Deployment of services involving personal data 


[Danger when not solved] No approval of deployment due to privacy legislations; lowered user 
acceptance 


[Concerned stakeholder] Developers of Interactive Traffic Management 

[Already addressed] Various academic approaches looking at the user side of C-ITS 

[Possible solutions] Applications which explicitly ask for user's consent before personal data is 
sent out, e.g. in PRICON project** 

15: Unclear liability in case of malfunctions or erroneous data 


[Description] System malfunctions or erroneous data may have legal and liability implications for 
actors. This is especially important for use cases that go beyond the “recommendation character”, 
e.g. displaying legally-binding traffic rules via in-vehicle devices. 

[Source] TM2.0 

[Effect on] Legally accepted concepts of Interactive Traffic Management 


[Danger when not solved] Impediment of viable business models; in case of concrete damages: 
complicated legal trials and possible high costs. 


[Concerned stakeholder] Developers of Interactive Traffic Management 


[Already addressed] On-going high-level discussions on “ethics” in context of Automated Driving, 
e.g. led by the German Ministry for Transport?? 


[Possible solutions] Proven liability models from previous projects 


16: Unspecified ownership of data 


[Description] Data ecosystems in Interactive Traffic Management may become quite complex, 
including various sources and processing steps. Eventually it is not clear who owns the (processed) 
data. 


[Source] TM2.0 


[Effect on] Legally accepted concepts of Interactive Traffic Management 


[Danger when not solved] Impediment of viable business models 
[Concerned stakeholder] Developers of Interactive Traffic Management 


[Already addressed] On-going higher-level discussions on “ownership of mobility data”, e.g. led by 
the German Ministry for Transport* 


[Possible solutions] Proven data ownership models from previous projects 








38 www.researchgate.net/profile/Thilo_Von_Pape/publication/321133930_A_Privacy-aware_Data_Access_System_for_Automotive_ 
Applications/links/5a0ed8baa6fdccd95db71 9cb/A-Privacy-aware-Data-Access-System-for-Automotive-Applications.pdf 

3° www.bmvi.de/SharedDocs/DE/Publikationen/G/bericht-der-ethik-kommission.html?nn=12830 

40 www.bmvi.de/SharedDocs/DE/Publikationen/DG/eigentumsordnung-mobilitaetsdaten.html?nn=12830 
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8.6. Conceptual bottlenecks 


17: Lack of political/societal acceptability 


[Description] Introduction of Interactive Traffic Management on a large scale will have implications 
to the current actors (e.g. changing their responsibilities) as well as to the society (influencing an 
individual's travel behaviour). Clear policies about the goals and approaches are required to reach 
a high level of acceptance among actors and users of such systems. To enable international roll 
out, the various national policies need to find acommon ground. 


[Source] TM2.0 

[Effect on] Societally accepted concepts of Interactive Traffic Management 
[Danger when not solved] Lower actor motivation; lowered user acceptance 
[Concerned stakeholder] Policy makers 


[Already addressed] A commonly accepted “Shared Vision” has been elaborated in SOCRATES2°, 
which may be used as a base for policy. 


[Possible solutions] Proven participation and communication concepts from previous projects 
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9. CONCLUSION 
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The SOCRATES?” project paves the way for the next generation of Traffic Management. 
Public and private parties cooperate to provide optimal routes (faster, safer, cleaner) 
for the individual road users, also securing the collective interests via mobile/in-car and 
roadside services and (in the future) self-driving vehicles. 


SOCRATES”? is based on the strategy developed by the TM2.0 initiative*!. It aims to agree 
on a set of common interfaces, principles and business models to facilitate the exchange 
of data between vehicles and TMC's. This is crucial for improving the entire value chain for 
consistent Traffic Management and mobility services. 


SOCRATES? will build on this strategy, elaborate an approach and test actual services in 
four regions in Europe. The elaborated concept of Interactive Traffic Management should 
be tested in reality before it can be widely deployed. Open questions will be discussed, for 
instance regarding optimal ways of cooperation, business models and legal framework. 
Further initiatives which SOCRATES?” builds on are (among others) the C-ITS deployment 
platform and C-Roads. 


The vision of the SOCRATES?" partners is that it will lead to a win-win-win situation for all 
actors in the Traffic Management eco-system: 


e Win for the road user: 
Effective Traffic Management depends on the acceptance by an individual traveller. 
However, a traveller a will only follow certain traffic management rules, when those 
rules are well-aligned between the various parties setting up the rules, and also 
efficiently communicated towards him. In this ideal case, the traveller will get a “one- 
stop-shop” of traffic information, based on coordinated Traffic Management strategies 
and algorithms. Also the traveller will be able to communicate back to the Traffic 
Management operators, giving feedback on current traffic flows and the efficiency 
of services. This way, each traveller will be respected as real customers of traffic 
infrastructure providers. 

e Win for public Traffic Management Centres: 
Traffic Management Centres will be able to substantially optimise Traffic Management 
operations. They will be able to address a wide range of road users with tailor-made, 
precise information, and will also take advantage of new communication channels and 
sensor/feedback techniques. Eventually, they will leave their current silo approach, 
trying to influence traffic operations by their own means. Instead, they become part 
of a holistic Traffic Management ecosystem, considering the expertise and assets of 
different parties and market players in the field of data detection, processing and 
communication. 





4 http://tm20.org/ 
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e Win for private Service Providers: 
Similarly, service providers will leave their current roles as pure navigation service 
providers for the individual traveller, based on own routing algorithms and barely 
considering collective information. Their information services will expand to seamless 
door-to-door traveller assistance. They will serve innovative use cases beyond 
navigation, such as showing available travel mode options, or giving lane-specific driving 
advice. All these new elements will be aligned with public, collective Traffic Management 
strategies, being part of sustainable cooperation models developed in SOCRATES?°. This 
way, they will take on active responsibility to improve efficiency and safety of our traffic 
systems. However, the specific set-up of services towards the travellers (being their 
costumers) will remain in the service provider's freedom, promoting the best solutions 
in a competitive market. 


To reach the mentioned win-win-win situation, some base concepts and common 
agreements need to be elaborated among the mentioned actors. This elaboration is mainly 
covered in SOCRATES?” Activity 2. 


The goal of Activity 2 is to develop an optimal framework for cooperation between the 
public and private partners, as a basis for a European deployment of Interactive Traffic 
Management. Activity 2 scopes the strategic level of such a cooperation, while the 
subsequent activities also cover the tactical and operational levels. 


The partners wanted to establish something new and not just improve an existing concept 
of cooperation. To do so, they recognised that a paradigm shift should be made from 
‘managing and influencing traffic’ to ‘supporting people on their travel from A to B’. Goal is 
to create synergies between actions of the individual road users with the collective mobility 
objectives, to bridge the innovative developments in the vehicle and in traffic management, 
while giving value to the legacy and creating new business opportunities. 

This goal is summarized in the following statements: 


Customer: CEO of my own journey! 

Community: Choosing our mobility habits 
Cooperation: Joint effort, shared benefit 
Technology: Facilitating the journey, unperceived 


Since the road user is a central element in the vision, specifying use cases is crucial to 
establish the link between road authorities, private service providers and road users. This 
was done around three themes: 


1. Smart routing 


2. Actual speed and lane advices 
3. Local information and hazardous warnings 
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Then, it is important to assess how the stakeholders can cooperate to be able to take these 
steps. For this a theoretical framework was created, describing options for cooperation. 
Finally, the concept of the intermediary was explored, based on the use cases and 
cooperation models. An intermediary is expected to have a role in data exchange 
coordination, aggregation, fusion, quality control and common picture. A set of typical 
options for the intermediary role has been defined and described. 


Now the common framework is defined in Activity 2, the approach will subsequently be 
specified for the four pilots in Activity 3. The plans are then validated in the actual pilots 
(Activity 4-7), and evaluated in Activity 8. The results will be used to update the framework 
(Activity 9). Information on the results of these activities will be published in future 
deliverables. 


In short: 


e There isa common ground for cooperation; 

e Some promising cooperation models are already identified; 

e The challenge for the next activities will be to keep a balance between the interests of 
each stakeholder (public and private goals); 

e Testing the various cooperation options in several use cases and on several locations 
will provide valuable insights. 
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GLOSSARY 


Interactive Traffic Management 

Traffic Management based on the interaction between the traveler, the vehicle and traffic 
management systems, with the objective of supporting end users in their individual travel 
and driving choices while being aware of the collective traffic management context. 


Interactive Traffic Management services 

Services based on usage and benefiting from the interaction between the traveler, the 
vehicle and traffic management systems. Typical interactive traffic management services 
are: 


e Advanced navigation services: individual turn by turn navigation taking into account 
road and traffic conditions predictions, also based on traffic management plans 

e Adaptive and dynamic traffic control: traffic management and control services with 
adaptive and dynamic decision making processes based on real time and historical 
traffic data 

e Traffic status and event detection: traffic state information service including real time 
event detection 


These services provide a basis for the identification of involved actors, data and value 
exchange, which can lead to identification of supporting business models. 


C-ITS Cooperative Intelligent Transport Service 

CAM Cooperative Awareness Message 

DENM Decentralised Environmental Notification Message 

EC European Commission 

ETA Estimated Time of Arrival 

ETSI European Telecommunications Standards Institute European Union 
FCD Floating Car Data 

FG Focus Group 

HSR Hard Shoulder Running 


IVI In-Vehicle Information 
IVS In-Vehicle Signage 
KPI Key Performance Indicator 


LCS Lane Control System 

OEM Original Equipment Manufacturer (in this report referring to car industry) 
SP Service Provider 

RA Road Authority 

RTTI Real Time Traffic Information 

TM Traffic Management 

TMC Traffic Management Centre 

TMP Traffic Management Plan 

VMS Variable Message Sign 
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APPENDIX: USE CASES 


Chapter 4 gives a short overview of the essence of the cases (high level descriptions). 
This appendix describes the use cases in detail. 


SMART ROUTING 


Service introduction 


Summary Cooperation between road authorities and navigation service providers on 
the generation and transmission of ‘smart routes’ to improve traffic flow and 
efficiency and to provide more reliable navigation solutions for the road user. 


Use cases The following requirements needs to be fulfilled to create a valid use case: 
. Ause case must describe the relevant stakeholders. 
. Ause case must provide value to a stakeholder. > Goal orientation 
. Ause case must be a complete narrative describing the story of how the 
value is provided. > Must have main and alternative flows 
. Ause case must stand alone. > No sequencing of use cases 
. Ause case must not describe system design. > Describe “What” instead “how” 


The following use cases may be implemented under consideration of these 

common design options: 

e The use case may include services for specific vehicle type. Another approach 
is using vehicle type as a distinguishing feature to base actions upon. 
Synchronisation with roadside units for less confusion and better alignment 
with strategy accounts for both use cases. One caveat should be mentioned: 
it might not be possible to completely align VMS texts and navigation advice 
to road users when different road users get a different advice in the same 
geographic location. This would mean a VMS would have to display two or 
more texts to accommodate all the road users (or: ‘check your in car device’). 
Two or more texts on VMS's are undesirable. 

Require a good information strategy to the road users. 
May be implemented on different levels of detail and cooperation (see FG3). 
May or may not use an intermediary to reach the goals. 


The following use cases have been identified so far: 
UC_SR_01: Optimising network traffic flow 
UC_SR_02: Individual routing towards public event locations 


The following actors have been identified: 
Road users 
Vehicle driver 
Service provider 
Road authority 
Road operator 
Traffic centre 
Intermediary 
Fleet operator 
Public transport operator 


Optional actors: 

* Police 

« Fire department 
* Hospitals 
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Use case functional description - Optimising network traffic flow 
Use case: function of the system, the desired behaviour (of the system and actors), 
specification of system boundaries and definition of one or more usage scenarios. 


Optimising network traffic flow 
Use case introduction 


Background 


Road users are advised routes that are optimal for the overall network 
performance and societal goals. 


Today, individual routing advice provided by service providers does not 
account for the network optimum and for higher-level policies of road 
authorities. This eventually results in conflicting route advices (from 


road authorities vs. service providers), and in decreasing efficiency 
of public traffic management measures. Also, the routes that service 
providers advise to the road users might be undermined by traffic 
management measures. Furthermore, service providers cannot 
accurately predict if congestion will occur on the advised route. 


By optimising the network usage and adhering to policy, optimised 
routing advice provided by service providers will help achieve societal 
goals, like increasing network efficiency, reducing emissions and 
improving traffic safety. 
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Desired behaviour 


Expected benefits 


The system will calculate the optimal route for individual road 

users based on collective road usage and network compatibility 
considerations. This should be related to the capacity of the road and 
higher-level network strategies. 


Also, the system will enable road authorities to request the service 
providers to specifically prefer or avoid specific network elements, 

with inclusion of an explanation (environmental, safety (e.g. school or 
retirement home), location quality, primary road for another modality 
(bike, public transport, pedestrians)). This measure can be also be 
addressed to specific road users (vehicle type, resident vs. non-resident 
etc.) or circumstances (time of day etc.). 


For a further optimal effect, current and planned travel patterns of road 
users will be analysed to determine the actual travel demand in a high- 
resolution picture regarding time and location. 


Road users will optimally comply and drive using the optimised 
navigation advice. This is accompanied by a concise (visual/textual) 
description of features of possible route options, including any 
advantages and hazards. The road user will still have the freedom to 
choose his favourite route. However, by being well-informed about 
the route options, it is most likely that he will follow the recommended 
“smart route”. 


This information can be produced pre-trip and on-trip. 


Design options: 

e Inclusion of multiple routes, including reasons why some routes are 
less attractive. When this is chosen there should be a discussion 
about the “default” route of “first” advice a service provider provides 
to the road users. 

Inclusion of incentives for road users accepting an optimal route 

for the network/societal goals (being a suboptimal route for the 
individual). The incentives might include: monetary reward, collecting 
virtual points, following a “social” route (and feeling good about that) 
and having a higher priority at traffic lights. Be aware that a monetary 
incentive might lead to undesirable situations (e.g. virtual sessions 
using GPS spoofing). 

Inclusion of incentives for fleet operators to route vehicles according 
to the road authorities’ goals (e.g. avoidance of certain network 
regions) 

Inclusion and information of dynamic tolls for specific road parts (e.g. 
the Liefkenshoektunnel). If the toll is lifted, this might entice certain 
road users to use the tunnel more often. 

Inclusion of multimodal navigation in order to reduce the overall 
traffic demand on the road network. The modes may be conventional 
public transport or private ride sharing services. 

Integration of a feedback loop for road authorities, who will receive 
information via the service providers, if a “smart route” is accepted 
and followed by a road user. This may help road authorities to 
evaluate and optimise their traffic management rules. 


Better network performance, better road usage (with respects to 
priorities, safety and environment), better navigation experience for 
road users (better ETA's, better RTTI). 
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Use case description 


Situation 


Actors and relations 


A service provider, road authority or intermediary has determined 
through algorithms that several road users will use a road that will 
probably (predictive) be congested. 

The prediction among others depends on the information about 
current traffic-related events such as hazards or road works, which are 
made available to the service providers and road authority (see use 
cases “Hazard Information’). 

Some or all of the users will receive a “smart route” navigation advice 
that will support the flow of the network. Depending on options that 
were chosen these users will get a choice of a different first or default 
route. 

The operator receives general information on the collective acceptance 
of the “smart route”. 


Exemplary implementation: 


Road user: Enters a destination (and origin if applicable) and receives 
optimised navigation advice. 


Road authority: sends data (probably through the intermediary) about 
the current and future road status, including specific network elements 


that have to be preferred or avoided (called “road desirability” below). 


Intermediary: The intermediary consolidates and validates information 
from multiple sources, relays relevant information and ensures there 
are no privacy concerns. This will mean that certain information flows 
will have to be aggregated, combined and/or stripped of information 
that can be used to tie the data to a specific person. 


Service provider: The service provider receives information from the 
road authorities (probably through the intermediary) and delivers 
information to road users. Also it delivers relevant information to the 


intermediary. 
So... 


Road status / 


<ori 
Road desirability | merme in / Destination — Service 
authority gia) rigin / Destination — Providers 


<= Road capacity — == Predicted road use 


Origin / Destination 
Route Speed 


Direction 
yo 
Q, Road user 
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Scenario 


Display / alert principle 


Functional Constraints / 
dependencies 


Example: An event takes places which will cause high traffic demand on 
the roads in its proximity. There are road users who do not like to visit 

the event but whose shortest route towards a destination would share 

network elements with visitors of the event. 


Based on service provider's algorithms and the road authority 
expertise, potential capacity bottlenecks along the network are 
identified. Also, the road authority has deemed certain roads less 
desirable, since there is a pollution problem on certain parts of the 
route. 


The intermediary exchanges information about traffic demand (from 
service providers) and network supply (from road authorities). The 
service providers can query the intermediary for relevant information 
in order to enhance individual route advices in form of a “smart route”. 


Pre-trip: When the road user starts his individual navigation service, 
“smart route” options are displayed, based on the data exchange 
described above. 

On trip: In case traffic conditions change, the “smart route” options are 
immediately updated, including an explanation for the change. 


For many data types required for the concept above, data formats 
and data communication techniques need to be agreed on: 
Geo-description of network elements and/or areas which are to be 
preferred or avoided (“road desirability”) 
Travel demand information 
Generic description of road user type (e.g. vehicle type, emission 
class, resident vs. non-resident) 
Information on features (e.g. reason and significance) of specific 
“smart routes” (e.g. eco-friendly route or social route) 
Road authorities will have to be able to automatically communicate 
information about the road status, road desirability and road 
capacities, in an interoperable, up-to-date and complete manner. 
Service providers will have to be able to automatically communicate 
travel demand information, in an interoperable, up-to-date and 
complete manner. 
In this context, travel demand information will have to go from 
one service provider to another. This might impact business 
opportunities. There is probably a solution using an intermediary. 
Further, travel demand information should be handled very carefully. 
This will have a privacy implication. 
Travel demand information can be derived from service providers, 
which gather any destination requests from road users. Since most 
service providers will be reluctant to share this information with 
competitors, the central intermediary may play a crucial role here. 
Since this party will receive all the information from all parties, this 
should be an impartial (with no ties to certain service providers) 


party. 
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Use case functional description - Individual routing towards public 
event locations 


Individual routing towards public event locations 


Use case introduction 


Provide smart routes (guidance) for certain destinations (e.g. events) 


Background Some events are visited by a huge number of people. Usually a 
significant part of these people intend to travel to the event in private 
vehicles. This stresses the overall infrastructure and likely causes 
congestion and high delays. Furthermore, the road user usually needs 
to find a parking lot where he leaves the ‘driving’ mode and switches to 
another mode (such as walking or public transport) in order to reach 
the final destination. 

This problem is usually addressed by local traffic managers, who try 
to optimise incoming traffic by dynamic parking information systems, 
advices to use P&R facilities, dynamic lane assignment etc. However, 
that kind of local traffic management is rarely communicated via 
navigation systems, resulting in decreased efficiency of local traffic 
management and inconvenience and confusion for the road user. 


Objective Road users that request a route to such a destination shall be 
supported by a route guidance that incorporates the traffic 
management measures of the organisation's strategies. For instance, 
road users can be guided to less occupied parking lots close to a 
festival. 


When approaching a certain destination, road users are guided until 
they reach their parking spot. This requires that information along the 
road (via VMS etc.) and in-car (via navigation devices) is up-to-date, 
consistent and comprehensive to the road users. 


It is also recommended to “dynamise” the destination information 

for the individual road user. Instead of routing to a fixed address/ 
coordinate, a most-suitable driving destination (e.g. a parking lot) will 
be decided by the system on-route, based on current traffic conditions. 


Design Options 

* Inclusion of multimodal navigation in order to reduce the overall 
traffic demand on the road network. The modes may be conventional 
public transport or private sharing services 

e It is possible that a predicted state of the network and a predicted 
state of the event location (for instance, amount of free parking 
spaces) are needed for an optimal travel experience. 


Desired behaviour Road users will adapt their driving behaviour, route choice and 
potentially mode choice based on local traffic management rules. 


Expected benefits Avoidance of negative traffic impacts in the context of events etc., 
increased comfort for road users, better navigation experience for road 
users. 
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Required data 


Road users current position and destination 

Depending of local traffic management: especially availability of free 
parking lots, availability of alternative travel modes, information on 
temporary lane closures/openings, routing strategy, etc. 

The event organiser will also have information that is relevant to 
the traffic flow: the time the event will start and end, the estimated 
amount of visitors and sometimes also the location the road users 
will most likely come from (origin). For SOCRATES the road authority 
may deliver this data. 

In order to calculate whether certain parking locations will end up 
full, when the road user will arrive at the event location, the amount 
of public transport data might also give an insight into the predicted 
traffic flow. Weather information might also be a good predictor on 
the amount of event attendees that will use the car as a mode of 
transport. 

“Dynamic” destination information for the individual road user 
(instead of a fixed address/coordinate, the navigation systems should 
be able to enter an event (e.g. “concert”) or a general area e.g. (“city 
centre”), and then determine the most-suitable driving destination 
during the trip, maybe including some options.) 
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Use case description 


Situation 


Actors and relations 


Scenario 


Display / alert principle 


Functional Constraints / 
dependencies 


The service providers system will be able to recognise a destination as 
an “event destination”. It will then offer a route to the road user that will 
minimise search traffic. 


Exemplary implementation: 


Road user: Enters a destination (and origin if applicable) and receives 
optimised navigation advice. 


Road authority: sends data (probably through the intermediary) about 
the current and future road status, including specific network elements 
that have to be preferred or avoided (called “road desirability” see 
previous use case). The road authority will also share the amount of 
free parking spaces, start/end time of the event, the predicted amount 
of visitors and public transport data. 


Service provider: The service provider receives information from the 
road authorities (probably through the intermediary). The service 
provider will route the road user to the optimal parking location. 


Optional intermediary: The intermediary consolidates and validates 
information from multiple sources, relays relevant information and 
ensures there are no privacy concerns. This will mean that certain 
information flows will have to aggregated, combined and/or stripped of 
information that can be used to tie the data to a specific person. 


Example: Several road users want to go to the Amsterdam ArenA. 
Therefore several road users will input the same destination. Also there 
is another event going on somewhat near the events in Amsterdam. 


Based on service provider's algorithms, shared data (visitors, parking 
information, etc) the road users receive a route to the most optimal 
parking location. 


The intermediary exchanges information. The service providers can 
query the intermediary for relevant information in order to enhance 
individual route advices in form of a “smart route”. 


Pre-trip: When the road user starts his individual navigation service, the 
road user is informed that he/she will drive to an event location. The 
system will ask if the road user wants to be directed toward a parking 
space. 

On trip: Road users must be informed of status changes in relation to 
the destination (e.g. parking lot is full, you will be rerouted). 


« Road authorities will have to be able to automatically communicate 
information about the parking spaces and event data, in an 
interoperable, up-to-date and complete manner. 

Service providers will have to be able to detect an event destination 
from user input. 

Service providers will have to be able to automatically update the 
destination of the road user, using the data that was mentioned in 
the use case. 
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ACTUAL SPEED AND LANE ADVICE 


Service introduction 


The service provides speed and lane advice to road users in order to 
improve traffic safety and traffic flow efficiency and to reduce traffic 
emissions. The use case also includes dynamic maximum speeds and 
red crosses, which are mandatory. 


UC_SLA_01: Maximum allowed speed 

UC_SLA_02: Speed advice “Congestion ahead” 
UC_SLA_03: Speed advice “Head of Congestion” 
UC_SLA_04: Speed advice at Traffic Lights 
UC_SLA_05: Speed advice at shockwaves 
UC_SLA_06: Lane information 

UC_SLA_07: Lane advice at short on- and off-ramps 
UC_SLA_08: Lane advice at Traffic Lights 


Maximum allowed OT 
Use case | Use case introduction = 


Maximum allowed speeds can be displayed to road users in the car. 
Multiple parameters are taken into account: 
the static speed signs 
the dynamic speed limits via matrix signs 
temporary speed limits, for example at road works 
time-dependent rules, for example during the day / night / specific 
hours 
weather-dependent rules, for example during heavy rain, smog-alerts 
vehicle-specific characteristics, for example trucks or caravans 


Background In case of temporary speed limits: In order to protect sites with 
incidents or road works, speed limits are advised or imposed. 


Objective Safety & Comfort. This should minimise any doubts on what the 
maximum allowed speed would be for any road user. 


In case of temporary speed limits: The aim is to alert the road user 
about the speed limit so that he can adapt his speed. 

Road users are given a speed advice when approaching road 

works, incidents or similar situations. Service providers will receive 
government data through the intermediary to reach this goal. Service 
providers will also have their own data. 


Desired behaviour In case of temporary speed limits: the road user adapts his driving 
behaviour complying to the applicable driving speed limit. 


Expected benefits In case of temporary speed limits: 
« Road authority: safer road use, less incidents. 
« Road user: improved safety and better informed. 
« Service provider: happier users, better service. 
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Use case description 


Situation In case of temporary speed limits (when road users are approaching 
road works, incidents, lost cargo, overcrowded streets (demonstrations/ 
manifestations) or chaotic situations (like taxi’s unloading or taking up 
passengers)): the traffic centre uses the lane control system (LCS) to 
display to the road speed limits. 

The same information could be displayed on an In-Vehicle Signage 
(IVS) service. On motorways that are not equipped with a physical lane 
control system (LCS): a virtual LCS could be used, providing the same 
information to the IVS service. IVS does not have the same legal stature 
as law or legal regulations, nor can provide the same legal authority 
and proof, so this would remain purely informational. it has to be 
clarified how legal binding can be also reached for virtual LCS. 

Remark: the road user should get a speed advice and explanation for 
the advice. 


Actors and relations In case of temporary speed limits: depending on the cooperation 
model, the actors could be: 

« Road user: Receive speed advice and change speed accordingly. 

« Road authority: deliver relevant data to the intermediary. This should 
at least include known incidents, planned and actual road works 
(with the addition of the type and amount of hindrance), planned and 
actual demonstrations, planned and actual chaotic situations. 
Intermediary: receive and send data between road authorities and 
service providers. 

Service providers: receive, use, validate and combine data. Send 
speed advices to road users, including the reason for the speed 
advice. 


Perhaps the intermediary also validates and combines data if this helps with the use case. 
This should be further investigated. 


Scenario In case of temporary speed limits: Depending on the cooperation 
model, the scenario could be: 
« The Traffic Centre takes the decision to install speed limits. 
« The vehicle receives information about speed limits. 
The road user adapts his driving behaviour (speed). 
Road authority is sending all known situations to the intermediary. 
Intermediary sends information to the service providers. 


— Events —> — Events — 
Road < Roadworks/closure > £ < Roadworks/closures I Service 
authority <— Incidents ——> Intermediary <— incidents Providers 
N 


Origin / Destination 
Speed Speed 
advice Direction 


Vv 


Road user 





Display / alert principle | Display info in-car to road user. 
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Functional Constraints / | In case of temporary speed limits: 

dependencies Many Traffic Centres use automated decision algorithms how/when 
to install speed limits along the road sections. Usually this is based on 
traffic flow detection at the specific VMS location. In the future (e.g. with 
a virtual LCS concept), these decision algorithms have to be revised, 
taking into account the extended possibilities: 
(a) to detect traffic flow and 
(b) to inform road user s. 
As dynamic speed limits and lane closures are legally binding traffic 
management measures, it has to be clarified how legal binding can be 
also applied for virtual LCS. 


Navigation functions and/or destination are needed if the speed 
advice is given in relation to a certain part of the route. If there is no 
destination set, the road user might take a different route, where 
there will be no congestion and the advice has no use. An exception 
to this rule is a road user driving on a road that will inevitably lead to a 
congested part. 


The most important aspect that must be realised in developing this 
service is avoiding contradictory information on the roadside and in- 
car. This might happen when the current signalling system stays active 
while the in-car system doesn't take this into account. A contradictory 
situation might occur when the current signalling system advises 50 for 
very close traffic jam, while the in-car system advises 70 for road users 
approaching road works. This should not occur. 


Required data Static and dynamic speed limits. 
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Use case functional description - Speed advice “Congestion ahead” 


Speed advice “Congestion ahead” 


Use case introduction 


Summary To anticipate the congestion on a road, the oncoming traffic must 
receive a lower speed advice. The recommended speed depends on the 
maximum allowed speed on the road and on the average measured 
speed in the congestion. 

Background Not only will the lower speed advice aid in countering the development 
of a (starting) congestion on the road but the warning will also help 
the road user in anticipating on time to the changing conditions 
downstream. In this way accidents in the tail of the congestion may be 
prevented. 


Objective Safety & Comfort. 
Queue tail protection (this should prevent head-tail accidents). 
Reducing congestion on the road. 

Desired behaviour The road user is able to anticipate on time, thereby reducing the 
congestion on a road. 

Expected benefits « Road authority: safer road use, less incidents. 
« Road user: improved safety and better informed. 


Use case description 


Situation When driving, road users will receive speed advice when there is a 
congestion ahead. 


The message might be very specific (for a less congested travel 
experience a speed of 70 is advised) or less specific (for less 

congested travel experience we suggest you slow down). However, if a 
combination with VMS is developed, a specific speed is preferred, which 
can be aligned with the speed on the VMS. 


This system will need a process to determine where speed advice will 
have a positive impact on (predicted) congestion. This means that the 
system should know the route the road user will take thus the road 
user is either using navigation or on a road that will inevitably lead to a 
congested part. 


Actors and relations Road user: Receive speed advice and change speed accordingly. 
Road authority: deliver relevant data to the intermediary. This data 
will help service providers to determine where congestion might 
occur and calculate/predict whether speed advice might alleviate the 
situation. Optionally showing the same speed advice on VMS. 
Service provider: receive, use, validate and combine data. And 
delivering speed advice to the road user. 

Intermediary: Receiving and delivering data for the use case. 
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Scenario Depending on the cooperation model: scenario could be: 


Scenario 1: 

Road user is approaching road works, incident, lost cargo, overcrowded 
street or chaotic situation. 

Road authority is sending all known situations to the intermediary. 
Service provider sends speed advice to road user including reason. 


Scenario 2: 
Road user is driving to a destination where congestion is expected on a 
part of the route. 


Road authority is sending intensities, travel times, incidents, event 
information, road closures/road works to the intermediary. 


The service provider receives the information from the intermediary 
and adds their own data sources. Either through a service request or 
their own algorithms, the service provider sends a speed advice to the 
road user. The service provider informs the intermediary of the speed 
advice. 


The road user receives the speed advice and changes speed. 


The intermediary receives information and turns this into a feed for 
road authorities. 


— Travel times > < origin / Destination — 


< origin / Destination — Service 
Intensities > i 
Intermediary < origin / Destination — Providers 


<< Speed advice — Speed advice — 


Road 
authority 


N 


Origin / Destination 
Speed Speed 
advice Direction 


Vv | 


Road user 


Display / alert principle | Display info in-car to road user 
Functional Constraints / | * Quality and availability of congestion data should be high enough. 
dependencies « Warning should reach road user s on time. 
Required data * Location of congestion 
* Location, heading and speed of incoming traffic participants 
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Use case functional description - Speed advice “Head of congestion” 


Speed advice “Head of congestion” 


Use case introduction 


Summary To reduce congestion on a road, road user s at the head of the queue 
can be advised to speed up. When leaving the queue (transition from 
congestion to free flow), road user s should keep the gaps with the 
vehicles in front of them short. 

Background When reaching the end (head) of congestion, road user s should 
speed up and follow closely to the road user s upfront. Speeding up 
at the head of the congestion will result in a faster dissolution of the 
congestion. 


Objective Traffic flow optimisation. 
Prevention of Capacity drop. 

Desired behaviour Road users change speed to comply with the advice given by service 
providers. 

Expected benefits Benefit to the road authority: improved traffic flow. 
Dissolution of traffic congestion. 
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Use case description 


Situation When reaching the head of the congestion, road user s should be given 
an in-car speed advice that will help in dissolving the congestion. The 
speed advice might be very or less specific. However, if a combination 
with VMS is developed, a specific speed is preferred, which can be 
aligned with the speed on the VMS. 


Actors and relations Road user: Receive speed advice and change speed accordingly. 
Road authority: deliver relevant data to the intermediary. This 
data will help service providers to determine where the head of 
the congestion might occur and calculate/predict whether speed 
advice might alleviate the situation. Taking speed advice on VMS into 
account if necessary. 
Service provider: receive, use, validate and combine data They will 
also deliver speed advice to the road user. 
Intermediary: Receiving and delivering data for the use case. 
Road authority, intermediary or service provider: Determining when 
and where a speed advice to road users will aid in the dissolution of 
the congestion. 


Scenario Depending on the cooperation model: scenario could be: 
Road authority is sending intensities, travel times, incidents, event 
information, road closures/road works to the intermediary. 


The service provider receives the information from the intermediary 
and sends a speed advice to the road user. The service provider 
informs the intermediary of the speed advice. 


Road users that are driving in congestion which is expected to end, will 
receive a message with speed advice. The road user will shortly after 
receiving the message change speed. 


The intermediary receives information and turns this into a feed for 
road authorities. 


Travel times => E Origin / Destination — 


< Origin / Destination — Service 
Intensities => i 
Intermediary < Origin / Destination — Providers 


< Speed advice — Speed advice => 


Road 
authority 


N 


Origin / Destination 
Speed Speed 
advice Direction 


y | 


Road user 


Display / alert principle | When arriving at the location where the congestion is ending, the road 
user can be warned in-car (with an app). 


Functional Constraints / | * Quality and availability of congestion data should be high enough. 
dependencies * Warning should reach road users on time. 
« Privacy regulation. 


Required data * Location of congestion head 
+ VMS information if available. 
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Use case functional description - Speed advice at traffic lights 


Speed advice at traffic lights 


Use case introduction 


Summary When a vehicle is driving towards a junction regulated by traffic lights, 
speed advice could be given to the road user such that he will pass 
the traffic lights during the green phase (=green wave). Unnecessary 
accelerating / decelerating can be avoided. 
Road users approaching traffic lights in cars receive a speed advice. The 
advice is based upon the predicted state of the traffic light (red/yellow/ 
green) and helps road users determine if they have to decelerate, 
drive the same speed or accelerate for optimal traffic flow. In the 
Netherlands, this will build upon the framework delivered by Talking 
Traffic. 


Background When approaching a traffic light road users driving cars have several 
options. They can slow down, because there is red or yellow light or 
they can speed up, since there is a green light. This service will give a 
speed advice to the road user concerning the traffic light. This means 
that the road user might no longer have to slow down or brake before 
ared light, because they know that they will go through a green light, if 


they change their speed to the advice. Also, road users will know that 
speeding up to go through a green light might be useless, since there 

is no way to reach the green light in time. This will reduce some of the 
guesswork and will lead to better traffic flow, less emissions and a safer 
driving experience. 


Safety is an essential goal in relation to this use case. In talking traffic 
there are many aspects taken into consideration. For instance: how 
many seconds before green to we let road users know the light will 
turn green? From what distance to the traffic light should the advice be 
given? Etc... 


Objective Reduction of traffic emissions. Improved traffic safety. Improved traffic 
flow. 

Desired behaviour Road users change speed to comply with the advice given by service 
providers. 


Expected benefits Benefit to the road user: Better informed, safer and lower gas usage, 
Benefit to the road authority: improved traffic flow and reduced gas 
emissions (especially for trucks). Benefit to the service provider: this is 
an additional service to the road users, which might lead certain users 
to prefer their solution over other solutions. 
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Use case description 


Situation The road user is approaching a traffic light. The road user receives a 
speed advice from the service provider. This advice might be in the 
form of a specific speed, but might also be in the form of a more 
generic advice (speed up, slow down, stay the same speed). 

The advice is based upon data from the (intelligent) traffic light. 


Actors and relations Road user: The road user uses a navigation solution while 
approaching a traffic light. 
Road authority: The traffic light sends out information about the most 
probable time the light turns green/yellow/red. This information is 
sent to the intermediary. 
Intermediary: Receiving and sending of information from road 
authority to the service providers. 
Service provider: Providing a speed advice based upon the data from 
road authorities. 


Scenario Depending on the cooperation model: scenario could be: 


« Road user approaches a traffic light. 

« The traffic light is sending out data to the intermediary. 

« Based upon the data the road user receives a speed advice.* 
« The road user changes speed. 


Service 


Ri A 
oad Spat/map —> Intermediary = Spat/map — Providers 


authority 


Traffic light data Origin / Destination 


(spat/map) Speed Speed 


advice Direction 


NA | 


Traffic 
Light Road user 


* There are many variables to take into account. For example: The distance to the traffic 
light, whether the vehicle is in motion or not, the state of the traffic light, the next light in 
the cycle (whether there is a time to green or a time to yellow/red). 
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Display / alert principle | Here we describe triggering conditions and what is displayed to the 
user when. 


Vehicle in motion? 


>100m? >100m? 


Red/green Red/green 


Look out: red E 
(speed advice for green 100%: No info - 5%: 
when 100% sure) speed. w. "forg, en 


Red is next, TTR in y sec 
4 “atch traffic light (watch TL) 


Red is next, watch TL TTGinysec 
Slow down and if 100% sure Red is next (>75%+reason), 
speed advice (<95%: see TL) 


(>75%: TTG in y sec, 
dan) see TL 


Functional Constraints / | For more details information from the talking traffic project should be 
dependencies used. 


Required data Location and direction of the different traffic lights (= MAP data) 
« Time-to-green (= SPAT data) 
* Time-to-red (= SPAT data) 
* Location, heading and speed of incoming traffic participants, high 
temporal resolution! 
« Number of vehicles waiting at the traffic light 
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Use case functional description - Speed advice at shockwaves 


Speed advice at shockwaves 


Use case introduction 


Summary By lowering traffic speed upstream of a shockwave, it is possible to 
reduce congestion or even to let a congestion shockwave disappear. 
The road user receives speed advice as he drives. The speed advice is 
given when a system determines that a certain speed will reduce the 
chance of congestion. Optionally the road authority can display the 
same advice on their Variable Message Signs (VMS). 


Background Showing the road user an advice to change speed. 


Objective Reduction of Congestion, shockwave damping. 


By reducing the intensity on certain roads, it is possible to reduce the 
amount of congestion. 


When road users are advised to slow down, they will arrive later at a 
location where there is a high probability (or actual present at the time) 
of congestion. This will decrease the amount of vehicles that contribute 
to the congestion, increasing the likelihood of a smaller amount of 
congestion and a lower period needed for the congestion to dissolve. 


Perhaps it is also possible an advice to speed up (while adhering to 
the speed limit) might have a positive effect on potential congestion, if 
keeping the same speed (or lower) will increase the likelihood that the 
road user will arrive at a certain location along with a large group of 
other road users. It will have to be determined if this is possible. 


There are two ways this system might work. One without additional 

VMS and one with VMS. 

1. Without additional VMS. Based on a predetermined rule based 
system and data an actor (road authority, intermediary or service 
provider)* determines when and where a speed advice to road 
users might help reduce or prevent congestion. Road users receive 
a speed advice. Information on the amount of informed road users 
is transmitted to the intermediary. The intermediary turns this into 
a feed for road authorities. Road authorities receive this information 
and use this to ensure the systems that trigger on travel times do not 
mistake slower traffic for congestion (and thus suppress additional 
action). 

. With additional VMS. Based on a predetermined rule based system 
and data an actor (road authority, intermediary or service provider)* 
determines when and where a speed advice to road users might 
help reduce or prevent congestion. Road users receive a speed 
advice. Additionally road authorities show the same speed advice 
on VMS. Since the road authority knows that there is a speed advice 
in action, systems can suppress additional actions based on slower 
traffic. 


* There is a case to be made to let any of the three involved parties determine when and 
where speed advice to reduce or prevent congestion. This should be further discussed. 


Desired behaviour Road users receive speed advice when it is pertinent. Road users 
change speed according to the speed advice. 
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Expected benefits 


Use case description 


Situation 


Actors and relations 


This will benefit the road authority: less congestion on the network. 
This will also benefit the road user: a more comfortable and informed 
driving experience. On the other hand, this might also be a detriment 
to certain road users: those that prefer less travel time over less time in 
congestion. 

This will finally benefit the service provider: this is an additional service 
to the road users, which might lead certain users to prefer their 
solution over other solutions. 


When driving, road users will receive speed advice when it is relevant to 
preventing congestion. 


The message might be very specific (for a less congested travel 
experience a speed of 70 is advised) or less specific (for less 

congested travel experience we suggest you slow down). However, if a 
combination with VMS is developed, a specific speed is preferred. This 
speed advice could be part of a TM scenario as well (e.g. involving ramp 
metering) 


This system will need a process to determine where speed advice will 
have a positive impact on (predicted) congestion. This means that the 
system should know the route the road user will take. This means the 
road user is either using navigation or the road user is on a road that 
will inevitably lead to a congested part. 


Road users will have to receive this message when it is pertinent. 
Hopefully, a large enough part of the road users adhere to the 
message. 


« Road user: While driving receiving messages and adhering to these 
messages. 
Road Authority: Delivering data for service providers to the 
intermediary. This data will help service providers to determine 
where congestion might occur and calculate/predict whether speed 
advice might alleviate the situation. Optionally showing the same 
speed advice on VMS. 
Service provider: Delivering speed advice to the road user. 
Intermediary: Receiving and delivering data for the use case. 
Road authority, intermediary or service provider: Determining when 
and where a speed advice to road users will reduce or prevent 
congestion. First thought: Since there are many road authorities and 
many service providers, it seems like the intermediary might be the 
best location to determine this. 
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Scenario Depending on the cooperation model: scenario could be: 
Road user is driving to a destination where congestion is expected on a 
part of the route. 


Road authority is sending intensities, travel times, incidents, event 
information, road closures/road works to the intermediary. 


The service provider receives the information from the intermediary 
and had their own data sources. Either through a service request or 
their own algorithms, the service provider sends a speed advice to the 
road user. The service provider informs the intermediary of the speed 
advice. 


The road user receives the speed advice and changes speed. 


The intermediary receives information and turns this into a feed for 
road authorities. 


Travel times > < Origin / Destination — 
Road mm : < origin / Destination — Service 
Intensities => 
authority intermediary < Origin / Destination — Providers 
<= Speediadvice —] Speed advice => 


N 


Origin / Destination 
Speed Speed 
advice Direction 


NZ | 


Road user 


Display / alert principle | When a situation occurs that can benefit from speed advice to road 
users. This will be based upon data and predictive technology. 
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Functional Constraints / 
dependencies 


Required data 


Navigation functions and/or destination are needed if the speed 

advice is giving in relation to a certain part of the route. If there is no 
destination set, the road user might take a different route, where there 
will be no congestion. An exception to this rule is a road user driving on 
a road that will inevitably lead to a congested part. 


Safety and advice compliance might be issues: it is unlikely that all (or 
even the majority of) road users will receive speed advice in relation 
to the (predicted) congestion. Therefore most surrounding road users 
will drive at a different speed. This might lead to an unsafe situation 
when road users comply to the advice. This issue can be mitigated 

by additionally using the road authorities VMS. This introduces a new 
issue: road users accustomed to speeds on VMS based upon very 
immediate congestion. When there is no congestion immediately, road 
users might lose trust in the signalling. 

Other road users driving at a different speed will probably impact 
advice compliance. 


The most important aspect that must be realised in developing this 
service is avoiding contradictory information on the roadside and in- 
car. This might happen when the current signalling system stays active 
while the new system doesn't take this into account. A contradictory 
situation might occur when the current signalling system advises 50 
for very close traffic jam, while the in-car system advises 70 to reduce 
congestion further on the road (because this system has determined 
that the road user is too close to reduce or prevent congestion by 
lowering the speed). This should not occur. 


Many details need further inspection: the distance from the congestion 
where the speed advice is given. The exact speed advice given in 
relation to the amount of congestion. Will we use VMS or not and if not: 
will this work with other road users driving at a different speed? Etc... 


e Location, heading and speed of incoming traffic participants, high 
frequent updates. 
* Lots of end users! 
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Use case functional description - Lane information 


Summary Provide in-car information on the actual and upcoming lane-situation: 
end of lane 
open/end of rush hour (or other temporary) lane 
open/end of interchangeable lane (lane dedicated to one driving 
direction depending on traffic) 
closed lanes due to incidents / road works. 


In case of hard shoulder running (HSR): The road user receives 
information that the hard shoulder is open to traffic and is 
recommended to use it. 


In case of closed lanes: the road user receives information about closed 
lanes due to incidents/road works as he drives. The message subject is 
the temporary closed lanes given by the Traffic Centre. Lane Closures 
may be also subject to specific vehicle types (e.g. “no lorries” etc.) 


Background In case of HSR, in general, the hard shoulder is underused. Road users 
tend to hesitate on using the hard shoulder. Hard shoulders are usually 
used for broken-down vehicles or for other emergencies. However, this 
is quite rare, therefore road capacity of hard shoulders is not fully used. 
In case of closed lanes: in order to protect sites with incidents or road 
works, lanes are blocked and/or closed. 


Objective Safety & Comfort. This should minimise any doubts on the lane- 
situation for any road user. 


In case of HSR: The aim is to urge the road user to use the hard 
shoulder. 


In case of closed lanes: The aim is to alert the road user about the 
closed lanes so that he can move on towards an open lane. 
Desired behaviour In case of HSR: Road users using the hard shoulder more frequently. 


Expected benefits In case of HSR: increased road capacity; reduce congestion upstream; 
improved traffic safety due to reduced overtaking by the right (on the 
hard shoulder). 





In case of closed lanes: leaving blocked/closed lanes more smoothly. 
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Use case description 


Situation 


Actors and relations 


Scenario 


Display / alert principle 


Functional Constraints / 
dependencies 


Required data 


In case of HSR: The road user receives information about the hard 
shoulder being open to traffic and is urged to use it as the right lane. 


In case of closed lanes: In case of an incident or road works, the traffic 
centre uses the lane control system (LCS) to display to the road user 
closed lanes (red cross). The same information could be displayed 

on an In-Vehicle Signage (IVS) service. On motorways that are not 
equipped with a physical LCS: a virtual LCS could be used, providing the 
same information to the IVS service. 


In case of HSR: 

« Traffic centre: takes decision to HSR and sends out the message. 

« Road user: The end-receiver that should benefit from this 
information, by receiving information on HSR. 

« Service provider: disseminates the message to the road user. 


In case of closed lanes: 

« Traffic centre: takes decision and sends out the message 

« Road user: The end-receiver that should benefit from this 
information, by receiving information on lane closures. 

« Service provider: disseminates the message to the road user. 


Depending on the cooperation model, the scenario could be: 


In case of HSR: 
The Traffic Centre takes the decision to HSR 
The vehicle receives information about HSR and the advice to use the 
hard shoulder as the regular right lane 
The road user adapts his driving behaviour 
The Traffic Centre permanently monitors the conditions on the 
hard shoulder. In case of detected broken-down vehicles or other 
emergencies, HSR is instantly out of operation. Vehicles and road 
users receive this information and are rerouted to regular lanes. 


In case of closed lanes: 

« The Traffic Centre takes the decision to close lanes (or gets informed 
about blocked lanes). 

e The vehicle receives information about closed lanes. 

« The road user adapts his driving behaviour (lane choice). 


In case of HSR: 

« Display info in-car to road user. 

« In the future: broken-down vehicles or other emergencies along the 
hard shoulder will be detected by the vehicle (via its sensors) or by 
the road users (via apps etc.) 


As lane closures are legally binding traffic management measures, it 
has to be clarified how a legal binding can be also reached for virtual 


Static and dynamic info on 
end of lane 
open/end of rush hour (or other temporary) lane 
open/end of interchangeable lane (lane dedicated to one driving 
direction depending on traffic) 
closed lanes due to incidents / road works. 
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Use case functional description - Lane advice at short on- and off-ramps 


Lane advice at short on- and off-ramps 


Use case introduction 


Summary On-ramp: 
A road user on the main road can be warned when there is a short on- 
ramp ahead. Lane advice could be to move to the left, especially when 
there is heavy traffic. 
Road users on the on-ramp can also be warned, especially when speed 
difference between main road and on-ramp is high. 


Off-ramp: 
Road users on the main road upstream of an off-ramp can be warned 


when there is a short off-ramp or when there is congestion on the off- 
ramp. 


Background Short off- and on-ramps are potentially dangerous situations especially 
during dense traffic, if the speed difference between the on-/ off-ramps 
and the main roads is high, or there is no clear line of sight. 

Providing in-car information about these potentially dangerous 
situations leads to the road user being able to anticipate to this 
situation on time. 


Objective Traffic Safety. 
Improving traffic flow. 

Desired behaviour Road users will be alerted in time when a dangerous situation occurs 
on short on-or off ramps and will be able to anticipate on time. 


Expected benefits Improved traffic flow and traffic safety. 
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Use case description 


Situation When driving on the main road with a short on-ramp ahead, a warning 
can be given towards the road user on the main road to move to the 
left lane or to give road users on the ramp space to move in. 

When arriving on a short on-ramp for merging on the main road a 
warning (+ speed advice) can be given to alert the road user for the 
short ramp. 


Actors and relations « Road user: While driving receiving messages and adhering to these 
messages. 
Road Authority: Delivering data for service providers to the 
intermediary. This data will help service providers to determine 
where short on-/off-ramps occur. 
Service provider: Delivering speed and/or lane advice to the road 
user. 
Intermediary: Receiving and delivering data for the use case. 
Intermediary or service provider: Determining when (during dense 
traffic? Time window?) and where (main road or on short ramp? 
Both?) a warning (and speed and/or lane advice) to road users will be 
send. 


Scenario Depending on the cooperation model, the scenario could be: 
The road authority sends information to the intermediary about lane 
configuration and all locations of the short ramps. 
The intermediary receives and delivers all necessary information 
(lane, configuration, location short ramps, traffic information, speed 
information nearby the short ramps, ...) for the use case. 
The service provider will receive the information and transform this into 
a useful warning (and speed advice) for the road user. 
The vehicle receives a warning (and speed advice) when arriving at a 
short on-/off- ramp. 
The road user adapts his driving behaviour (speed). 


Display / alert principle | The road user on the main road receives a warning when approaching 
a short ramp. This could contain a lane (and speed) advice. 
A road user who will use the ramp will receive a warning (and speed 
advice) when arriving on the ramp. 


Functional Constraints / | Data provided by the road authorities should be sufficiently detailed. 
dependencies 
Required data Location of the on-and off-ramps. 

Lane configuration of the ramps and main roads. 
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Use case functional description - Lane advice at traffic lights 


Lane advice at traffic lights 


Use case introduction 


Summary Redistribution of traffic over lanes in order to utilise the available 
capacity better and to optimise traffic throughput. 


Background With good in-car information it has become possible to give customised 
advice in terms of speed, route, etc. Advising road users with lane 
information at traffic lights in order to redistribute traffic over available 
lanes will result in more efficient traffic flows. 

Objective Traffic flow optimisation, reduction of congestion. 

Desired behaviour Road users will be redistributed over the available lanes which will 
result in more efficient traffic flows. 

Expected benefits Traffic flow optimisation. 

Reduction of congestion. 


Use case description 


Situation When road users arrive at (unknown) complex crossroads, it can be 
helpful to receive lane advice upfront. Especially when there is dense 
traffic and when this traffic is un-equally distributed over the lanes (for 
example: on one lane there is congestion and the other lane is open 
and free). 

A lane advice could distribute road users equally over the available 
lanes which will result in less congestion and less waiting time. Less 
(complicated) lane changes will have to be made by people, also 
reducing congestion. 


Actors and relations « Road user: While driving receiving messages and adhering to these 
messages. 
* Road Authority: Delivering data for service providers to the 
intermediary. 
« Intermediary: Receiving and delivering data for the use case. 
« Service provider: Delivering lane advice to the road user. 


Scenario Depending on the cooperation model, the scenario could be: 
A road user arrives at a traffic light with multiple available lanes. He will 
receive a message with lane advice from the service provider. 
The lane advice will be based on the route of the road user and on the 
information received from the Intermediary. The latter will gather the 
information from different road authorities. 
The information requested from the road authorities are lane 
configuration, traffic information, speed information nearby traffic 
lights, traffic density of the different lanes, ... 


Display / alert principle | A message with lane advice is given when the traffic is not equally 
distributed over the different lanes. 

Functional Constraints / | Data should be detailed enough to estimate densities on the different 

dependencies lanes. 


Required data Traffic speeds & intensities at different locations upstream of the traffic 
light (e.g. 20m and 200m upstream of traffic light). 
Position & speed of individual vehicles approaching the traffic light 
(high temporal resolution). 
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LOCAL INFORMATION AND HAZARDOUS WARNINGS 


Service introduction 


Summary 


Use cases 





Local Information and Hazardous Warning aim is to inform and warn 
vehicles on local situations and receiving feedback on the information 
from road users based on the current real world situation. 


* UC_LIHW_01: Road Works Warning 

* UC_LIHW_02: Road condition warning 

* UC_LIHW_03: Emergency Service protection 

* UC_LIHW_04: Environmental/Areal information and constraints 


Feedback loop 
LinHaHub 
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Use case functional description - Road Works Warning 


Road Works Warning 


Use case introduction 

Summary The road user receives notifications as he/she drives. The message 
subject are Environmental Notification and Warning Messages. 

Background Alert the user, on upcoming changes to the normal and to be expected 
driving situation. 


Objective The objective is to warn every passing vehicle and provide all 
available and relevant information, in a harmonised, timely and non- 
contradicting way, on the section of road it approaches, to the vehicle. 
And also to receive input/update information from the road user on 
new or current road works. 


Desired behaviour The vehicle receives all information and displays the information to the 
road user or makes it available to the drive system. The road user can 
give feedback when the current situation is different from the situation 
described by the data through the services which delivers the info to 
the user. 


Expected benefits Every road user/vehicle is aware of all current and oncoming road and 
driving conditions. Every road authority /service provider is aware of 
the current and updated road and driving conditions. 


Use case description 


Situation A vehicle approaches a section of road on which road works are 
located. The incident involves an oil leakage and as a consequence a 
slippery road on lane 2. 


Actors and relations The central system that holds the current information and condition of 
the road (this can be either put in manually of automatically). Roadside 
system for message delivery at/around the incident location. Passing 
traffic (either direction) for receiving the information. An intermediary 
should/could check and validate all retrieved information. 


Scenario A vehicle approaches and is within distance of a known road works 
site. It receives a warning message for the location of the road works. 
The warning message contains information on changed speed limits 
and lane restriction and layouts related to the road works site. The 
warning messages are transmitted from a central system. The central 
system generates a broader/wider/more general warning message to 
be broadcasted within a larger catchment area. The general warning 
message is broadcasted by roadside equipment within the relevant 
catchment area. The warning message is received by on-coming traffic 
and the vehicle acts accordingly. This can be done directly, by changing 
to another lane, or indirectly by advising the road user to change to 
another lane, or no warning is displayed as the vehicle has established 
that itis driving on a different road within the catchment area and 
the vehicle will not directly pass the incident location. The road user 
can give feedback on the reported road works through the services 
provider (information valid, situation changed, etc) that delivered the 
information. The road user can also report new road works to the 
services provider the system did not report on. 
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Display / alert principle | The vehicle displays/acts on the message when the path of the vehicle 
is crossing the location of the incident. 


Functional Constraints / | Generating, sending and receiving of DEN-messages must be possible 


dependencies and a central system has to be in place to receive and redistribute 


the various messages and warnings. On-board vehicle status must be 
known. 
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Use case functional description - Road Condition Warning 


Road Condition Warning 


Use case introduction 

Summary The road user receives notifications as he drives. The message subject 
are Environmental Notification and Warning Messages. 

Background Alert the user, on upcoming changes to the normal and to be expected 
driving conditions. 


Objective The objective is to warn every passing vehicle and provide all 
available and relevant information, in a harmonised, timely and non- 
contradicting way on the section of road the vehicle approaches. And 
also receive input/update information from the road user on changed 
road conditions. 


Desired behaviour The vehicle receives all information and displays the information to the 
road user or makes it available to the drive system. The road user can 
give feedback when the current situation is different from the situation 
described by the data. 


Expected benefits Every road user/vehicle is aware of all current and oncoming road and 
driving conditions. Every road authority /service provider is aware of 
the current and updated road and driving conditions 


Use case description 


Situation A vehicle approaches a section of road on which the road condition has 
changed. The incident involves a pothole on lane 2. 


Actors and relations The central system that holds the current information and condition of 
the road (this can be either put in manually of automatically). Roadside 
system for message delivery at/around the incident location. Passing 
traffic (either direction) for receiving the information. An intermediary 
should/could check and validate all retrieved information. 


Scenario A vehicle detects an abnormity in the road surface. It generates a 
warning message for the location. The warning messages are relayed to 
a central system. The central system generates a broader/wider/more 
general warning message to be broadcasted within a larger catchment 
area. The general warning message is broadcasted by roadside 
equipment within the relevant catchment area. The warning message 
is received by on-coming traffic and the vehicle acts accordingly. This 
can be done directly, by changing to another lane and/or reduce speed, 
or indirectly by advising the road user to change to another lane or 
reduce speed, or no warning is displayed as the vehicle has established 
that it is driving on a different road within the catchment area and the 
vehicle will not directly pass the incident location. The road user can 
give feedback on the reported road condition through the services 
provider that delivered the information. The road user can also report a 
new road condition warning to the services provider the system did not 
report on. 


Display / alert principle | The vehicle displays/acts on the message when the path of the vehicle 
is crossing the location of the incident. 


Functional Constraints / | Generating, sending and receiving of DEN-messages must be possible 
dependencies and a central system has to be in place to receive and redistribute the 
various messages and warnings. 
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Use case functional description - Emergency Service protection 


Emergency Service protection 
Use case introduction 


Summary The road user receives notifications as he drives. The message subject 
are Environmental Notification and Warning Messages 


Background Alert the user, on upcoming emergency services active on driving lanes. 


Objective The objective is to warn every passing vehicle and provide all 
available and relevant information, in a harmonised, timely and non- 
contradicting way on the section of road the vehicle approaches. 


Desired behaviour The vehicle receives all information and displays the information to the 
road user or makes it available to the drive system. The road user can 
give feedback when the current situation is different from the situation 
described by the data. 


Expected benefits Every road user/vehicle is aware of all current and oncoming road and 
driving conditions. 


Use case description 


Situation A Road Marshall is deployed at an incident location. The Road Marshall 
(or his/her vehicle) sends a warning message indicating where he/she is 
located and how traffic has to avoid him/her. 


Actors and relations The central system that holds the current information and condition of 
the road (this can be either put in manually of automatically). Roadside 
system for message delivery at/around the incident location. Passing 
traffic (either direction) for receiving the information. 


Scenario A Road Marshall is deployed at an incident location. The Road Marshall 
(or his vehicle) sends a warning message indicating where he/she is 
located and how traffic has to avoid him/her. The warning messages 
are relayed to a central system. The central system generates a 
broader/wider/more general warning message to be broadcasted 
within a larger catchment area. The general warning message is 
broadcasted by roadside equipment within the relevant catchment 
area. The warning message is received by on-coming traffic and the 
vehicle acts accordingly. This can be done directly, by changing to 
another lane, or indirectly by advising the road user to change to 
another lane, or no warning is displayed as the vehicle has established 
that it is driving on a different road within the catchment area and the 
vehicle will not directly pass the incident location. 


Display / alert The vehicle displays/acts on the message when the path of the vehicle 
principle is crossing the location of the incident. 


Functional Constraints / | Generating, sending and receiving of DEN-messages must be possible 
dependencies and a central system has to be in place to receive and redistribute the 
various messages and warnings. 
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Use case functional description - Environmental/Areal information 
and constraint 


Environmental/Areal information and constrain 
Use case introduction 


Summary The road user receives information as he drives. The message subject 
are Environmental Notification and Warning Messages. 

Background Alert the user, on upcoming environmental and/or Areal constraints 
and/or limitations. 


Objective The objective is to inform vehicles on upcoming driving limitations. 


Desired behaviour The vehicle receives all information and displays the information to the 
road user or makes it available to the drive system. The road user can 
give feedback when the current situation is different from the situation 
described by the data. 


Expected benefits Every road user/vehicle is aware of all current and oncoming road and 
driving constraints. 


Use case description 


Situation A vehicle is approaching an area with access limitations. For instance it 
is entering a city area. 


Actors and relations The central system transmits the current access limitations for that 
location to every passing vehicle. The information message is received 
by a passing vehicle. The vehicle assesses the received information. 


Scenario Access to a city is restricted for vehicles with a high emission value. A 
vehicle is approaching the city limits. The central system transmits the 
current access limitations for that location to every passing vehicle. 
The information message is received by a passing vehicle. The vehicle 
assesses the received information. The vehicle presents its findings on 
access limitations to the road user or the vehicle subsystem. If needed 
the vehicle plans a different route and/or changes its destination to the 
nearest point of the original destination where driving is allowed. 


Display / alert The vehicle displays/acts on the message when the path of the vehicle 
principle is crossing an area where the vehicle is not allowed to travel. 


Functional Constraints / | Generating, sending and receiving of DEN-messages must be possible 
dependencies and a central system has to be in place to receive and redistribute the 
various messages and warnings. 
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